Сообщение Re[9]: Почему в расте отсутствует выброс исключений? от 06.12.2022 14:33
Изменено 06.12.2022 14:34 vsb
Re[9]: Почему в расте отсутствует выброс исключений?
Здравствуйте, alex_public, Вы писали:
_>>>Ну, то что ты описал — это как раз случай не исключительной ситуации, а обычной обработки ошибок и соответственно удобнее это обрабатывать не исключениями, а через Result.
vsb>>Нет, удобней это обрабатывать именно исключениями. Т.к. при этом мне не нужно писать никакого кода.
_>Твоя фраза подразумевает, что при обработке с исключениями не надо писать какой-то код, который надо писать при обработке ошибок через Result в Rust'e. И т.к. это очевидно не код самой реакции на ошибку (который естественно надо писать в любом подходе и языке), то тогда о чём собственно речь? Или ты считаешь "дополнительным кодом" несколько знаков вопроса?
Ну смотри. Может я в расте что-то не понимаю.
Во-первых у каждой функции с ошибками надо возвращать Result вместо конкретного типа. Это как минимум синтаксический шум.
Во-вторых если функция сейчас не бросает ошибок, а завтра начинает бросать, мне надо менять её тип, потом проходить по всем местам её использования и как минимум добавлять туда этот самый вопросик. Потенциально надо рекурсивно менять тип этой вызывающий функции и так далее.
В-третьих — да, вопрос это дополнительный код с не такой уж и тривиальной логикой. И один символ тут не должен вводить в заблуждение.
В-четвёртых можно пример, как будет выглядеть код аналогичный
есть у меня подозрение, что вопросиком тут не отделаешься. Конечно на выходе нужен именно список чисел, а не список результатов.
vsb>>OOM в жаве это отдельная иерархия, но в целом — да, если отвечать на вопрос — пытается. И у него скорей всего получится, т.к. на нижнем уровне там всё используется в пулах преаллоцированных. Хотя, конечно, в условиях OOM всё будет плохо. У меня такой ситуации практически не бывает, но если про это задумываться, я при OOM предпочёл бы просто завершить процесс.
_>Именно! И как раз для таких ситуаций исключения (или паники) подходят идеально.
Насчёт исключений — хз. В жаве есть какой-то флажок, который при первом же OOM-е просто завершает процесс вместо выбрасывания исключения (и вроде хипдамп пишет). Вот это правильный подход и если бы мне не было лень это прописывать, я бы его прописывал.
_>>>А что именно неудобно в работе с Result?
vsb>>Ну в го неудобно то, что там под каждым вызовом функции еще 3 строки на обработку err. В расте сахарок сделали, но всё равно везде Result-ы мусорят же. Зачем мне это видеть.
_>Ну тут есть довольно простой ответ, через встречный вопрос. ))) Вот допустим ты используешь механизм исключений для обработки обычных ошибок. Можешь ли ты взяв произвольную функцию в коде точно перечислить список ошибок, который она может вернуть?
Нет, конечно (ну если не считать throws, который был плохой идеей).
Но зачем? Всё, что я знаю — что он может кинуть Exception. Если мне нужно что-то более конкретное — я пойду в нужное место и посмотрю.
В Java придумали throws в своё время который как раз позволяет типы выбрасываемых исключений добавлять в сигнатуру функции. Но это оказалось плохой идеей и сейчас эту фичу стараются избегать.
_>>>Ну, то что ты описал — это как раз случай не исключительной ситуации, а обычной обработки ошибок и соответственно удобнее это обрабатывать не исключениями, а через Result.
vsb>>Нет, удобней это обрабатывать именно исключениями. Т.к. при этом мне не нужно писать никакого кода.
_>Твоя фраза подразумевает, что при обработке с исключениями не надо писать какой-то код, который надо писать при обработке ошибок через Result в Rust'e. И т.к. это очевидно не код самой реакции на ошибку (который естественно надо писать в любом подходе и языке), то тогда о чём собственно речь? Или ты считаешь "дополнительным кодом" несколько знаков вопроса?
Ну смотри. Может я в расте что-то не понимаю.
Во-первых у каждой функции с ошибками надо возвращать Result вместо конкретного типа. Это как минимум синтаксический шум.
Во-вторых если функция сейчас не бросает ошибок, а завтра начинает бросать, мне надо менять её тип, потом проходить по всем местам её использования и как минимум добавлять туда этот самый вопросик. Потенциально надо рекурсивно менять тип этой вызывающий функции и так далее.
В-третьих — да, вопрос это дополнительный код с не такой уж и тривиальной логикой. И один символ тут не должен вводить в заблуждение.
В-четвёртых можно пример, как будет выглядеть код аналогичный
List<Integer> parseStrings(List<String> strings) {
return strings.stream().map(s -> Integer.parseInt(s)).toList();
}есть у меня подозрение, что вопросиком тут не отделаешься. Конечно на выходе нужен именно список чисел, а не список результатов.
vsb>>OOM в жаве это отдельная иерархия, но в целом — да, если отвечать на вопрос — пытается. И у него скорей всего получится, т.к. на нижнем уровне там всё используется в пулах преаллоцированных. Хотя, конечно, в условиях OOM всё будет плохо. У меня такой ситуации практически не бывает, но если про это задумываться, я при OOM предпочёл бы просто завершить процесс.
_>Именно! И как раз для таких ситуаций исключения (или паники) подходят идеально.
Насчёт исключений — хз. В жаве есть какой-то флажок, который при первом же OOM-е просто завершает процесс вместо выбрасывания исключения (и вроде хипдамп пишет). Вот это правильный подход и если бы мне не было лень это прописывать, я бы его прописывал.
_>>>А что именно неудобно в работе с Result?
vsb>>Ну в го неудобно то, что там под каждым вызовом функции еще 3 строки на обработку err. В расте сахарок сделали, но всё равно везде Result-ы мусорят же. Зачем мне это видеть.
_>Ну тут есть довольно простой ответ, через встречный вопрос. ))) Вот допустим ты используешь механизм исключений для обработки обычных ошибок. Можешь ли ты взяв произвольную функцию в коде точно перечислить список ошибок, который она может вернуть?
Нет, конечно (ну если не считать throws, который был плохой идеей).
Но зачем? Всё, что я знаю — что он может кинуть Exception. Если мне нужно что-то более конкретное — я пойду в нужное место и посмотрю.
В Java придумали throws в своё время который как раз позволяет типы выбрасываемых исключений добавлять в сигнатуру функции. Но это оказалось плохой идеей и сейчас эту фичу стараются избегать.
Re[9]: Почему в расте отсутствует выброс исключений?
Здравствуйте, alex_public, Вы писали:
_>>>Ну, то что ты описал — это как раз случай не исключительной ситуации, а обычной обработки ошибок и соответственно удобнее это обрабатывать не исключениями, а через Result.
vsb>>Нет, удобней это обрабатывать именно исключениями. Т.к. при этом мне не нужно писать никакого кода.
_>Твоя фраза подразумевает, что при обработке с исключениями не надо писать какой-то код, который надо писать при обработке ошибок через Result в Rust'e. И т.к. это очевидно не код самой реакции на ошибку (который естественно надо писать в любом подходе и языке), то тогда о чём собственно речь? Или ты считаешь "дополнительным кодом" несколько знаков вопроса?
Ну смотри. Может я в расте что-то не понимаю.
Во-первых у каждой функции с ошибками надо возвращать Result вместо конкретного типа. Это как минимум синтаксический шум.
Во-вторых если функция сейчас не бросает ошибок, а завтра начинает бросать, мне надо менять её тип, потом проходить по всем местам её использования и как минимум добавлять туда этот самый вопросик. Потенциально надо рекурсивно менять тип этой вызывающий функции и так далее.
В-третьих — да, вопрос это дополнительный код с не такой уж и тривиальной логикой. И один символ тут не должен вводить в заблуждение.
В-четвёртых можно пример, как будет выглядеть код аналогичный
есть у меня подозрение, что вопросиком тут не отделаешься. Конечно на выходе нужен именно результат над списком чисел, а не список результатов над числами.
vsb>>OOM в жаве это отдельная иерархия, но в целом — да, если отвечать на вопрос — пытается. И у него скорей всего получится, т.к. на нижнем уровне там всё используется в пулах преаллоцированных. Хотя, конечно, в условиях OOM всё будет плохо. У меня такой ситуации практически не бывает, но если про это задумываться, я при OOM предпочёл бы просто завершить процесс.
_>Именно! И как раз для таких ситуаций исключения (или паники) подходят идеально.
Насчёт исключений — хз. В жаве есть какой-то флажок, который при первом же OOM-е просто завершает процесс вместо выбрасывания исключения (и вроде хипдамп пишет). Вот это правильный подход и если бы мне не было лень это прописывать, я бы его прописывал.
_>>>А что именно неудобно в работе с Result?
vsb>>Ну в го неудобно то, что там под каждым вызовом функции еще 3 строки на обработку err. В расте сахарок сделали, но всё равно везде Result-ы мусорят же. Зачем мне это видеть.
_>Ну тут есть довольно простой ответ, через встречный вопрос. ))) Вот допустим ты используешь механизм исключений для обработки обычных ошибок. Можешь ли ты взяв произвольную функцию в коде точно перечислить список ошибок, который она может вернуть?
Нет, конечно (ну если не считать throws, который был плохой идеей).
Но зачем? Всё, что я знаю — что он может кинуть Exception. Если мне нужно что-то более конкретное — я пойду в нужное место и посмотрю.
В Java придумали throws в своё время который как раз позволяет типы выбрасываемых исключений добавлять в сигнатуру функции. Но это оказалось плохой идеей и сейчас эту фичу стараются избегать.
_>>>Ну, то что ты описал — это как раз случай не исключительной ситуации, а обычной обработки ошибок и соответственно удобнее это обрабатывать не исключениями, а через Result.
vsb>>Нет, удобней это обрабатывать именно исключениями. Т.к. при этом мне не нужно писать никакого кода.
_>Твоя фраза подразумевает, что при обработке с исключениями не надо писать какой-то код, который надо писать при обработке ошибок через Result в Rust'e. И т.к. это очевидно не код самой реакции на ошибку (который естественно надо писать в любом подходе и языке), то тогда о чём собственно речь? Или ты считаешь "дополнительным кодом" несколько знаков вопроса?
Ну смотри. Может я в расте что-то не понимаю.
Во-первых у каждой функции с ошибками надо возвращать Result вместо конкретного типа. Это как минимум синтаксический шум.
Во-вторых если функция сейчас не бросает ошибок, а завтра начинает бросать, мне надо менять её тип, потом проходить по всем местам её использования и как минимум добавлять туда этот самый вопросик. Потенциально надо рекурсивно менять тип этой вызывающий функции и так далее.
В-третьих — да, вопрос это дополнительный код с не такой уж и тривиальной логикой. И один символ тут не должен вводить в заблуждение.
В-четвёртых можно пример, как будет выглядеть код аналогичный
List<Integer> parseStrings(List<String> strings) {
return strings.stream().map(s -> Integer.parseInt(s)).toList();
}есть у меня подозрение, что вопросиком тут не отделаешься. Конечно на выходе нужен именно результат над списком чисел, а не список результатов над числами.
vsb>>OOM в жаве это отдельная иерархия, но в целом — да, если отвечать на вопрос — пытается. И у него скорей всего получится, т.к. на нижнем уровне там всё используется в пулах преаллоцированных. Хотя, конечно, в условиях OOM всё будет плохо. У меня такой ситуации практически не бывает, но если про это задумываться, я при OOM предпочёл бы просто завершить процесс.
_>Именно! И как раз для таких ситуаций исключения (или паники) подходят идеально.
Насчёт исключений — хз. В жаве есть какой-то флажок, который при первом же OOM-е просто завершает процесс вместо выбрасывания исключения (и вроде хипдамп пишет). Вот это правильный подход и если бы мне не было лень это прописывать, я бы его прописывал.
_>>>А что именно неудобно в работе с Result?
vsb>>Ну в го неудобно то, что там под каждым вызовом функции еще 3 строки на обработку err. В расте сахарок сделали, но всё равно везде Result-ы мусорят же. Зачем мне это видеть.
_>Ну тут есть довольно простой ответ, через встречный вопрос. ))) Вот допустим ты используешь механизм исключений для обработки обычных ошибок. Можешь ли ты взяв произвольную функцию в коде точно перечислить список ошибок, который она может вернуть?
Нет, конечно (ну если не считать throws, который был плохой идеей).
Но зачем? Всё, что я знаю — что он может кинуть Exception. Если мне нужно что-то более конкретное — я пойду в нужное место и посмотрю.
В Java придумали throws в своё время который как раз позволяет типы выбрасываемых исключений добавлять в сигнатуру функции. Но это оказалось плохой идеей и сейчас эту фичу стараются избегать.