Comments 13

Checked exceptions определённо отжили своё. Не взлетела идея. Через дебри лямбд им придётся продираться всё сложнее. Уже в восьмёрке в связи с этим добавили UncheckedIOException. Осталось UncheckedSQLException, UncheckedInterruptedException и т. д. И заживём!

>>Оказалось, что в большинстве случаев разработчики их либо игнорируют, либо логируют, либо заворачивают в unchecked.
Миллионы мух не могут ошибаться.

Ну да много кода и что? Вы же не в блокноте свои приложения разрабатываете! checked меньше шансов что исключение будет обработано не корректно. Основная проблема unchecked исключений — документирование, документирование и еще раз документирование. У программистов обычно сложности с соблюдением всех регламентов, особенно в сжатые сроки.
По сути должна быть золотая середина.
PS.

Figure 15: Sample Code illustrating use of Custom Exception picked from Bruce’s blog
Ну не верю я что Брюс Эккель мог написать «высвобождение ресурсов» в try блоке.


Квест что выбрасывает NPE, Refrence.MOD_VERSION — константа
instance == null? ошибка реализации: getCurrentRecomendedBuild() — без комментариев…
Должна была быть статья о том что «checked исключения не нужны», а получилась о «большинство разработчиков не умеют с ними работать»
Им бы подучиться, а потом делать такие громкие заявления…
Вы бы хоть писали с чем не согласны.
Ничего не имею против checked исключений и по сему не понимаю к чему тут холивар? Буду признателен если поделитесь своим видением, с удовольствием пересмотрю свою точку зрения.
В какой момент стало хорошей практикой пустые кэч блоки?
«Кто-нибудь знает, что происходит в Windows в этот момент на самом деле?» проверяется совместимость софта с версией винды и наличие известных конфликтов.
UFO landed and left these words here
По поводу checked exceptions двоякие мысли:
С одной стороны, да, видно, что народ их не использует так, как было задумано во многих случаях. Заворачивают в unchecked, просто пропускают, хорошо если еще логи и стектрейсы будут. И вроде бы надо избавиться от этого.

С другой стороны, когда я вижу код, в котором это не спускается на тормозах, где исключения честно обрабатываются, где они не заворачиваются в unchecked, а как минимум, попробовавши какие то локальные действия, и не получивши результата, заворачивают это в другое checked exception и выкидывают дальше, например когда SQLException превращается в хорошо оформленный какой-нибудь самодельный DataAccessException, с указанием на то, что же все таки случилось, вот такой код мне нравится. Его проще читать, поддерживать и дорабатывать.
Причем на небольших проектах этого не заметно. А вот на больших, многоуровневых, модульных — очень даже.

Лично я стараюсь обрабатывать исключения нормально. Согласен, не всегда это в принципе возможно, но где возможно — обрабатываю.

Да, то как это сейчас многими используется — это не хорошо. Но однозначно выпиливать я бы не стал.
Я бы уже стал бы. Уже примерно понятно, чем их можно заменить — это что-то типа монады either, когда ваш метод может возвращать либо результат, либо ошибку. checked exception — это ошибка, прописанная в сигнатуре метода. Хотите ее вернуть — верните явно.

Это не замена 1 в 1, по очевидным причинам — выкинутое исключение можно ловить на много уровней выше. Но это адекватный механизм, проверенный временем. И вы не можете просто игнорировать ошибку, почти также, как исключение — потому что результат успешного выполнения из either нужно еще достать, и если его нет — то это достаточно явно.

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

Не вобще выпилить — а выпилить из API. Для начала из своего.
Можно подумать, вашу монаду не будут пустым get-ом раскрывать.

Проблема в том, что создатели языков программирования обычно бесконечно далеки от своих пользователей. Unchecked-исключения позволяют плохо написанному коду работать хорошо. Потому, что ошибка вылетает наверх и обрабатывается инфраструктурным кодом (это проще). Checked-исключения гасятся пустым try-catch (это проще), в итоге код работает некорректно и в лучшем случае свалится каким-нибудь NPE на следующей строчке, а в худшем случае испортит данные.

Поэтому для реального мира с позавчерашними дедлайнами и завтрашними выпускниками-разработчиками Unchecked Exceptions это лучший вариант из всех, которые сегодня есть.

Будут, и что? Это нужно сделать точно также явно, как обработать checked исключение. И точно также можно схалявить. Но эти места точно также будут видны при review кода, и завтрашним выпускникам можно будет надавать по шапке и попросить так больше не делать.


Я не говорю, что это идеальный вариант. Но это достаточно хорошо работающий вариант.


А что до unckeched всегда… так извините, их ловля "где-то наверху", это вовсе не "хорошо". Не заведомо так. В ряде случаев это не более чем попытка исправить все пост-фактум, когда ошибка уже была, и не обработана там где нужно — потому что ваш инфраструктурный код зачастую уже не знает контекста, и не может не только исправить, но даже в лог ничего путного записать — потому что без контекста анализ логов ничего не дает.


Вот скажем хороший пример — в spring jdbc вместо checked SQLException есть кучка разных unchecked. Это проще? Несомненно. Дает ли это гарантии от неверной работы? Да никаких абсолютно.

> Будут, и что? Это нужно сделать точно также явно, как обработать checked исключение. И точно также можно схалявить.

Верно. Поэтому я и пишу, что это то же самое с теми же проблемами. И как checked-исключения в своё время казались хорошей идеей, но на практике оказались плохой, так и тут будет.

> Но эти места точно также будут видны при review кода, и завтрашним выпускникам можно будет надавать по шапке и попросить так больше не делать.

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

> А что до unckeched всегда… так извините, их ловля «где-то наверху», это вовсе не «хорошо». Не заведомо так. В ряде случаев это не более чем попытка исправить все пост-фактум, когда ошибка уже была, и не обработана там где нужно — потому что ваш инфраструктурный код зачастую уже не знает контекста, и не может не только исправить, но даже в лог ничего путного записать — потому что без контекста анализ логов ничего не дает.

Сообщение + стектрейс в 90% случаев позволяет однозначно идентифицировать проблему, поэтому в лог записать есть что. Исправить не получится, да, но обычно это не имеет смысла. Откатить транзакцию и ответить «ошибка» это нормальный исход для очень многих случаев.

> Вот скажем хороший пример — в spring jdbc вместо checked SQLException есть кучка разных unchecked. Это проще? Несомненно. Дает ли это гарантии от неверной работы? Да никаких абсолютно.

Это лучше по той простой причине, что эти исключения долетят до самого верха, откатят транзакцию и залоггируются с точным местом вызова. А проверяемое исключение в 80% случаев будет проигнорировано и выполнение кода продолжится. insert упал из-за duplicated key? catch {} и идём обновлять «только что вставленную» запись, как ни в чём не бывало. Ой, это была не та запись и мы обновили чужие данные? Узнали про это полгода спустя, когда получили штраф от налоговой? Обидно, да.
Сообщение + стектрейс в 90% случаев позволяет однозначно идентифицировать проблему, поэтому в лог записать есть что.


Это тривиально неправда. Покажите мне обработку SQLException, скажем при попытке вставить дубликат — тогда я вам, может быть, поверю. А так. именно ваш пример как раз и не позволяет обработать исключение где-то выше — вы не знаете данных, и не знаете, почему они дублируются и с чем. Тоже самое будет практически с любой вариацией SQL (data truncation скажем). Вам подвалило пара миллионов записей из внешнего источника, вы попытались сделать INSERT, получили ошибку — и нет, просто откатиться и сказать "ошибка" недостаточно, потому что вы не знаете, на каких данных это произошло. Вы просто не вставили запись, причем неизвестно какую, и штраф вам точно также прилетит — просто за другие нарушения.
Не надают, не попросят, по разным причинам.


В моих проектах — надают еще как. Просто потому, что как checked, так и в меньшей степени — Either это средства времени компиляции, и поэтому инструменты для выявления некорректной работы с ними давно существуют. Инспекция кода в IDEA например их отлично ловит. Да, pattern matching к сожалению полноценно реализовать нельзя, но даже то что есть в javaslang скажем есть — уже показывает при компиляции, если вы не обработали оба варианта. Так что я при желании об этих проблемах узнаю до внедрения в продакшн, а не при падении через два месяца.
Вам ведь статистику в статье привели. Вы в неё не верите?


Вообще-то у меня своего опыта навалом, чтобы верить в чью-то статистику просто так. Я ее просто иначе интерпретирую. Примерно половина обработчиков — это логирование (первые два пункта). И? Что изменится, если тут будут unchecked исключения? Вы будете ловить и обрабатывать "хорошо" в одном месте, много уровней выше? Не-а.
Only those users with full accounts are able to leave comments. Log in, please.