Почему я не люблю логику на исключениях

[metaclass]

Один жабист утверждает что исключения надо ловить и обрабатывать, а не дать им нахрен свалится в корень вызова и пусть тот, кто вызывает, разбирается. Ну в жабе по другому сложнее, это понятно.
Но я не люблю обрабатывать исключения самостоятельно, за исключением "вывел в лог с данными приведшими к исключению и кинул дальше".
Потому что в таком случае баги становятся расходящимися. Хороший баг - это когда ВСЕ СДОХЛО, КОРОВЫ, ЗАБОРНИКИ, СТЕКТРЕЙС, МЯСО КРОВЬ КИШКИ. Умирает от входа. Сразу видно, где что надо исправлять.
А плохой баг: это когда он был, но мы его не видели, иначе как чтением логов каждый день за чаем. А хуже того - если мы исключение от него перехватили и пошли работать дальше, а в состоянии программы уже поселилось маленькое скрытое червие которое потом дальше где-нибудь приведет к еще худшим, уже непонятным ошибкам. Впрочем, такое редко бывает, если корректно работать - транзакции там при ошибках откатывать, внешние ресурсы закрывать в finally и вообще возвращаться в корректное состояние.
Но лучше все-таки вернутся в корректное состояние в finally, отписаться в лог в catch и бросить исключение дальше - пусть главный цикл оконных сообщений или там веб-сервер разбирается, у него голова больше.

Comments

[falcrum.livejournal.com]

Не всегда хорошо - особенно, когда пользуешь что-то стороннее. Оно, бывает, эксепшенами просто поносит, и валить это всё на экран - юзер запарится...

[schegloff.livejournal.com]

Жабист прав, поскольку в изрядном числе жабных библиотек исключения - это способ вернуть результат (типа what yuo want - not found), а не смертельная ошибка.

Ну и из реальной практики, лучше иметь внешне работающую неработающую программу, чем внешне неработающую работающую. Кровь и мясо - это для разработчика хорошо, а клиент от них нервничает.

[n16bs.livejournal.com]

>Ну и из реальной практики, лучше иметь внешне работающую неработающую программу
Круто потом фиксить продакшен базу, после того как её пол года грыз червь.

[volodymir-k.livejournal.com]

Намного лучше её фиксить, чем если бы бизнес её и приложение тихо списал из-за неиспользования юзерами.

А вообще конечно лучше быть и здоровым и богатым и умным и сразу всё делать чётко без ошибок.

[max630.livejournal.com]

бывает, что и действительно лучше не делать ничего. А бывает что похер что делать, лишь бы картинка была хорошая

[n16bs.livejournal.com]

Зависит от специфики взаимоотношений клиента и исполнителя. В нашем случае гораздо лучше если клиент будет неделю созерцать эксепшены и стектрейсы, но в базу черви не пролезут.

[n16bs.livejournal.com]

Что-то я не понял посыл поста. Что не нужно глушить исключения, с которыми в данном конкретном месте ничего нельзя сделать? Ну так это же заповедь, выбитая на скрижалях, чего тут обсуждать.

[bydl0coder.livejournal.com]

+++

[d4s.livejournal.com]

так классика же:
http://mobwiki.ru/%D0%A4%D0%B8%D0%BB%D0%BE%D1%81%D0%BE%D1%84%D0%B8%D1%8F_UNIX#.D0.A0.D0.B5.D0.B9.D0.BC.D0.BE.D0.BD.D0.B4:_.D0.98.D1.81.D0.BA.D1.83.D1.81.D1.81.D1.82.D0.B2.D0.BE_.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BC.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F_.D0.B2_UNIX
правило восстановления

[berezovsky.livejournal.com]

что такое мобвики ру?

[d4s.livejournal.com]

без понятия. в поисковике одна из первых ссылок по нужному мне вопросу. проверил, что то что надо и запостил.

[berezovsky.livejournal.com]

Спасибо Вам. Благодарен Вам.

[volodymir-k.livejournal.com]

Во-первых, исключения это не что-то особенное явовское, идею поддерживали все языки 90-х типа Ada, CLU, eiffel и т.д.

Во-вторых, проблему определения точки обработки исключения никто окончательно не решил (на любом языке), это эвристическая инженерная задача, иногда очень сложная из-за дополнительных требований типа "спросить у юзера, если не против, то проигнорировать 1 ошибку в пакете и продолжить дальше." Мир вообще местами сложен. Если вам какой-то пионер советует всегда сразу ловить и сразу обрабатывать все исключения -- ну пометьте себе, что он иногда гонит туфту.

В-третьих, а какая альтернатива исключениям? errno?

[n16bs.livejournal.com]

Альтернатива из мира функциональщины - Either и паттернматчинг.

[jdevelop.livejournal.com]

вот я тут хочу дико ругаться сейчас, ибо таскать эту Control.Monad.Error или там Either и смотреть на сигнатуры функций и способы их обработки с лифтами мучительно больно

[metaclass.livejournal.com]

Альтернативы исключениям и нету особой.
Я обычно делаю так: для заведомых ошибок - исключения. Пусть валится.
Для исключений "не у меня" - перехват и далее - или выброс дальше, или же обработка и код возврата.
Для операций, которые по определению могут быть ошибочными (пользователь ввел не тот пароль) - код возврата.

Коды возврата офомлены методом "имитируем хаскель на java/c#" - базовый класс-генерик с двумя наследниками - один сигнализирует об ошибке и тащит с собой информацию о ней, второй об удаче и тащит с собой результат. В параметрах класса-генерика - тип для удачного результата, и тип для неудачного результата.

[n16bs.livejournal.com]

А что тягаете в качестве объекта для неудачного результата? Те же эксепшены, что-то своё или каждый раз разное?

[metaclass.livejournal.com]

Как паук из розетки в голову надиктует :)
Иногда исключение, иногда сообщение для пользователя читабельное, все равно на уровне GUI никто не знает что с этой ошибкой делать, кроме "показать сообщение пользователю и повторить попытку".

[jdevelop.livejournal.com]

Ад, черви! не пишите на хаскеле в жабе, я вам прошу

[metaclass.livejournal.com]

"А будешь плохо себя вести - в аду будешь код функциональщиков на жабе переписывать".

[max630.livejournal.com]

можно не обрабатывать, а перебросить RuntimeError или как его там, или в исключение разрешённое для данной функции. в жабе очень хорошо что можно указывать исходный exception, таким образом весь стек сразу видно до истинной причины

[mr-st.livejournal.com]

Поступаю примерно также. В самых простых случаях все ловится на самом верху и логируется.Если писать логику обработки на каждый чих то код превращается в нечитабельный кал.

[swizard.livejournal.com]

В CL есть прикольная штука: рестарт, с её помощью можно достаточно ловко работать с кондишнами (аналогов я не видел ни в одном другом языке).

Например, есть библиотека, читающая utf-8 поток, она используется в библиотеке, которая парсит xml, а эта библиотека используется в коде юзера, который, например, читает какой-нибудь конфиг.

И тут раз, в потоке встретился невалидный utf-codepoint, и самый нижний уровень выкидывает исключение (кондишн). В java-like языках на этом месте уже ничего не сделать (конфиг не прочитан), а в CL можно ругнуться в лог и вызвать рестарт первой библиотеки: "Замени этот мусор на пробел". После этого вся конструкция спокойно дочитает конфиг.

Конечно, подобное поведение можно спрограммировать и в джаве: например, передавать вниз по стеку какой-нибудь флаг "игнорировать невалидные символы". Профит CL здесь в том, что рестарт программируется только один раз в том месте, где может возникнуть исключительная ситуация (в самой первой библиотеке вычитывания юникодного потока), а все остальные уровни про него знать не обязаны. В джаве же в моём примере разборщик xml-я должен иметь в виду, что вычитывальщик юникода может обломаться в данной конкретной ситуации. Ну и реакция на исключение может быть гораздо гибче настроена.

В качестве дополнительного бонуса: непойманный никем рестарт вылавливает REPL и, в режиме диалога, предлагает варианты реакции уже программисту :) Например, по исключению типа 'file-not-found можно тут же в репле поправить путь до файла и продолжить выполнение программы, а не рестартить весь проект.

[gds.livejournal.com]

1. в большинстве случаев лучше упасть сразу и с хорошей диагностикой, факт.
2. исключения в интерфейсах -- ад, мерзкий и кошмарный. Обычно он проявляется либо в необходимости везде ловить исключения, либо в исключениях, идущих из глубины, через несколько уровней библиотек/модулей.
Если возможно, библиотека/модуль должны предоставлять такой интерфейс, в котором вызов функции библиотеки/модуля возвращает только значение, конкретное и чёткое, а не заставляет оборачивать вызов в ловлю исключения.
(кстати, к лентяйке у меня подобная претензия -- там применение аргумента к функции возвращает не значение, а задержанное вычисление, которое 1. может свалиться где-нибудь в другой точке программы или зациклиться, 2. будет использовать ресурсы (процессор, память) в другой точке программы. при строгой модели вычислений таковых проблем нет: если значение есть, то оно есть, оно не может быть "ошибкой вычисления", программа упадёт именно при создании этого значения -- при вызове библиотечной функции, например. и, если значение есть, то с ним можно работать любыми способами, которыми возможно, без необходимости что-то вычислять.)

[nealar.livejournal.com]

1 у меня на х-е наблюдалось в виде исключений, которые полетают сквозь catch. Ибо нефиг тырить бездумно устройство исключений из совсем других языков!

[gds.livejournal.com]

о да, тоже замечаю такое, когда камлоёбствую с манатками. По сути, тот catch -- ну ровно те же исключения.

[sergiej.livejournal.com]

Эксепшн предназначен для исключительных ситуаций, которых тупо не должно происходить при работе приложения. Поэтому заворачивать их в общем случае - зло. Но в частных стучаях, когда криворукие бросают эксепшны по любому поводу, просто обрабатывая негативный сценарий, это уродский стиль, который преврашает жабу в ещё худший ад чем она есть, такие эксепшны не грех завернуть и в лог написать: тут був брошен уродский эксепшн, мы его обработали и продолжаем дальше, ибо это не эксепшн

[vit-r.livejournal.com]

Обычно это делает assert, который включается в отладочном режиме и выключается в продакшене.