?

Log in

No account? Create an account

(un)checked exceptions (Java) - Узором созвездий по мантии ночи

27.06.2018, Среда

16:55:00 - (un)checked exceptions (Java)

Previous Entry Поделиться Next Entry

Вышла тут бурная дискуссия с коллегой на тему того, вредны (его мнение) или полезны (моё) checked exceptions. Он ссылался на то, что мол большинство уже пришло к тому, что лучше без них, что возлагавшиеся на них надежды на практике не оправдались, а потому пусть всё (ну или почти всё) будет наследоваться от RuntimeError, и уже на уровне договорённостей следить, чтобы всё ловилось и ловилось вовремя. Мне такой вариант не нравится, мбо сам я пока что за свой не очень большой опыт писания на Java имел от checked exceptions больше пользы, чем неудобств.

Знаю, что есть у меня во френдах джависты не просто "опытнае", а даже "матёрые" ;)
Что скажете?

This entry was originally posted at https://arilou.dreamwidth.org/1831905.html. Please comment there using OpenID.

Comments:

[User Picture]
From:aantero
Date:27.06.2018 15:10:57
(Link)
Заранее прошу прощения, если вопрос был _только_ к френдам.

Я работал на нескольких Java проектах пять лет, по большей части чинил, поддерживал и надстраивал проекты, созданные раньше.
По поводу checked exceptions могу сказать следующее: как правило, они либо "проводились" через сигнатуры методов через весь стек вызова наверх, либо на каком-то этаже стека заворачивались в unchecked exceptions и выкидывались дальше.

Дело в том, что в абсолютном большинстве случаев никакой осмысленной обработки для checked exceptions придумать было нельзя, кроме как вернуть пользователю сообщение об ошибке, а сам exception сохранить в логе. Этим обычно занимается специальный обработчик, общий для всего приложения. Фреймворк, на котором приложение построено, словит любое необработанное исключение и отправит обработчику, checked или unchecked, но для checked придется еще немного кода написать для достижения этого результата, а с unchecked это происходит без вмешательства программиста.
(Ответить) (Thread)
[User Picture]
From:arilou
Date:01.09.2018 19:26:46
(Link)
Спасибо за мнение.
Просто в моём пока не столь богатом опыте на Java был уже случай, когда специфичные для приложения checked exceptions в некотором модуле логики, имевшие чуть выше уровнем (далеко не на уровне фреймворка) некую обработку, потом помогли, когда потребовалось подружить этот модуль с несколько иным контекстом. Наличие экспшенов, которые надо обработать или задекларировать в заголовке метода, порой помогало быстрее понимать, в каком случае там в глубине вызова может случиться вполне предусмотренная логикой ошибка (и её надо поймать, а не дать ей лететь наверх), а где вызов безопасен.

В итоге я пришёл пока к мнению, что checked exceptoins не абсолютное зло, а вподне применимы в случаях, когда исключение нужно поймать "где-то выше", но ещё на пол-пути до того места, где ловятся все дикие исключения, и тот факт, что метод "небезопасный" лучше пометить явно, чем потом поймать это при тестировании (а то и в проде).
(Ответить) (Parent) (Thread)
[User Picture]
From:aantero
Date:01.09.2018 20:29:40
(Link)
Мне кажется, такие вещи нужно оставлять на усмотрение программиста. Обработчики исключений мне писать приходилось, но, как ни странно, это ни разу не были обработчики для checked exceptions, выкидываемых из методов какого-то библиотечного класса. А именно библиотечные классы и поставляют большинство checked exceptions в код.
То есть, это не абсолютное зло, да. Это фича, которая имеет ограниченную полезность, но используется неправильно чуть менее, чем везде, включая стандартные классы самой Java. Суммарный (невеликий) вред от них на круг получился больше, чем суммарная же польза. Когда checked exceptions присутствуют в сигнатуре библиотечного метода (а тем паче, когда их три штуки), то в 99.(9)% случаев это зло. Какая разница, почему поезд дальше не идёт, если поправить ситуацию можно только _до_ вызова, а после вызова только и остаётся, что ошибку логировать? Случаи, когда ошибку можно адекватно обработать и ехать дальше, гораздо более редки, а кроме того, непредсказуемы для того, кто пишет библиотеку.
Специфичные для приложения checked exceptions - это другой случай. Здесь, действительно, они могут служить для само-документации кода. Впрочем, и тут считается, что лучше бы обойтись без них, т.к. обработка исключений несколько "дороже", чем обычная логика. Почти все обработчики, которые я писал, просто оборачивали одну ошибку в другую и/или выполняли какое-то действие, прежде чем выкинуть ошибку дальше. Т.е., в большинстве случаев исключение - это капут. Если это ещё не капут, предпочтительно обойтись обычной логикой. Хотя, с другой стороны, вечный бой "читаемость vs перформанс"...

В общем, не торчали бы они наружу из библиотек - были бы просто редко используемой синтаксической приправой, но так как исторически их использовали именно для торчания наружу из библиотек, то и слава у них соответствующая.
(Ответить) (Parent) (Thread)