История изменений
Исправление tailgunner, (текущая версия) :
Ну и когда они таки сроабатывают, это другие накладные расходы.
И кого это волнует, если их использовать правильно (то есть именно как исключения)?
Тех, кого интересуют предсказуемые программы.
Вот мы делаем долгую работу, парсим всякие данные и в любой момент может случится невосстановимый облом. Зачем нам замусоривать интерфейс и реализацию пробросом «ошибки»?
«Замусоривать интерфейс»? Интерфейс должен отражать реальность и если функция может завершится ошибочно, это _должно_ быть отражено в ее интерфейсе. В случае возврата Result это делается явно, в случае исключения - менее явно (исключения не являются частью сигнатуры), но количество «мусора» в обоих случая одинаково. Проброс ошибки, конечно, следует как-то подсахарить, но это не проблема.
Я считаю, что исключения - это просто ещё один полезный инструмент
Естественно. И если они есть в языке, следует хорошо подумать, прежде чем отказаться от их использования. Но в случае с Rust вопрос в том, а стоит ли _добавлять_ этот инструмент.
которому уже 40+ лет.
есть как минимум один мэйнстримный язык без исключений... Си!Какие забавные взаимнопротиворечивые аргументы.
В чем противоречие? 40 лет назад в CLU начаты эксперименты, и мы можем сравнить опыт потомков CLU с опытом от еще более старого Си.
А так как recover возвращает значение, то так даже можно пробрасывать информацию. Прямо как с обычными исключениями.
Окей. Но там же:
«The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values».
Т.е. инструмент ограниченного внутреннего использования. Как longjmp в Си. А в интерфейсах - возврат пары значений.
Исходная версия tailgunner, :
Ну и когда они таки сроабатывают, это другие накладные расходы.
И кого это волнует, если их использовать правильно (то есть именно как исключения)?
Тех, кого интересуют предсказуемые программы.
Вот мы делаем долгую работу, парсим всякие данные и в любой момент может случится невосстановимый облом. Зачем нам замусоривать интерфейс и реализацию пробросом «ошибки»?
«Замусоривать интерфейс»? Интерфейс должен отражать реальность и если функция может завершится ошибочно, это _должно_ быть отражено в ее интерфейсе. В случае возврата Result это делается явно, в случае исключения - менее явно (исключения не являются частью сигнатуры), но количество мусора в обоих случая одинаково. Проброс ошибки, конечно, следует как-то подсахарить, но это не проблема.
Я считаю, что исключения - это просто ещё один полезный инструмент
Естественно. И если они есть в языке, следует хорошо подумать, прежде чем отказаться от их использования. Но в случае с Rust вопрос в том, а стоит ли _добавлять_ этот инструмент.
которому уже 40+ лет.
есть как минимум один мэйнстримный язык без исключений... Си!Какие забавные взаимнопротиворечивые аргументы.
В чем противоречие? 40 лет назад в CLU начаты эксперименты, и мы можем сравнить опыт потомков CLU с опытом от еще более старого Си.
А так как recover возвращает значение, то так даже можно пробрасывать информацию. Прямо как с обычными исключениями.
Окей. Но там же:
«The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values».
Т.е. инструмент ограниченного внутреннего использования. Как longjmp в Си. А в интерфейсах - возврат пары значений.