История изменений
Исправление KivApple, (текущая версия) :
Зачастую обрабатывать ошибку надо очень далеко от места, где она возникла.
По банальной причине - нельзя её как-то специфично обработать. Можно только выйти, перезапустить всю операцию или отобразить пользователю красивое сообщение об ошибке.
Представь вот загрузку файла по HTTPS. Оно может быть реализовано в десятках функций и даже в нескольких модулях. TCP, TLS, HTTP, работа с файлами. Но по факту ошибка на любом уровне имеет одни и те же последствия - закрыть все файлы/сокеты, которые успели открыть, и либо вывести сообщение об ошибке, либо попытаться заново с нуля.
Специфичеая локальная обработка ошибок нужна и в принципе возможна в меньшем числе случаев.
Поэтому 90% кодов ошибок прокидывается в вызываемую функцию. И неплохо иметь для этого какой-то сахар, чтобы программист видел реальный алгоритм работы программы, а не гору if err != nil, в которых теряется основной смысл.
Впрочем, в Rust эта проблема по сути решена оператором вопроса (когда ошибка ожидаема) и unwrap (когда ошибки не должно быть принципиально, например, при парсинге константной строки или если в коде выше уже есть проверка условия).
Исходная версия KivApple, :
Зачастую обрабатывать ошибку надо очень далеко от места, где она возникла.
По банальной причине - нельзя её как-то специфично обработать. Можно только перезапустить всю операцию или отобразить пользователю красивое сообщение об ошибке.
Представь вот загрузку файла по HTTPS. Оно может быть реализовано в десятках функций и даже в нескольких модулях. TCP, TLS, HTTP, работа с файлами. Но по факту ошибка на любом уровне имеет одни и те же последствия - закрыть все файлы/сокеты, которые успели открыть, и либо вывести сообщение об ошибке, либо попытаться заново с нуля.
Специфичеая локальная обработка ошибок нужна и в принципе возможна в меньшем числе случаев.
Поэтому 90% кодов ошибок прокидывается в вызываемую функцию. И неплохо иметь для этого какой-то сахар, чтобы программист видел реальный алгоритм работы программы, а не гору if err != nil, в которых теряется основной смысл.
Впрочем, в Rust эта проблема по сути решена оператором вопроса (когда ошибка ожидаема) и unwrap (когда ошибки не должно быть принципиально, например, при парсинге константной строки или если в коде выше уже есть проверка условия).