Исключения

Throwable — корень всего, что можно бросить или поймать. У него два прямых подкласса: Error, сигналящий о серьёзных сбоях уровня JVM вроде OutOfMemoryError, которые ловить не следует, и Exception, моделирующий проблемы приложения. Собственный подкласс Exception — RuntimeException — непроверяемый, а любое другое Exception проверяемое.

throw — это оператор в теле метода, который прямо сейчас возбуждает один конкретный экземпляр исключения, например throw new IOException(). throws — это часть сигнатуры метода, объявляющая, какие проверяемые исключения метод может пробрасывать вызывающему, чтобы тот знал, что их нужно обработать или переобъявить. Один действует, другой объявляет.

Проверяемые исключения — подклассы Exception, кроме RuntimeException; компилятор требует от вызывающего либо обработать их, либо объявить через throws, поэтому они моделируют восстановимые ситуации вроде отсутствующего файла. Непроверяемые — подклассы RuntimeException и Error — не требуют объявления и обычно сигналят об ошибках в коде или фатальных условиях, восстановление от которых не предполагается.

Java просматривает блоки catch сверху вниз и входит в первый, чей тип совместим с брошенным исключением, поэтому подкласс должен идти первым: сначала catch (FileNotFoundException e) и только потом catch (IOException e). В обратном порядке широкий блок уже обрабатывает подкласс, узкий становится недостижимым, и компилятор его прямо отвергает.

Объявите оба ресурса в одном заголовке try через точку с запятой. Закрываются они в порядке, обратном объявлению, поэтому программа печатает open A, open B, close B, close A. Обратный порядок гарантирован языком: поздний ресурс часто построен поверх раннего. Каждый объявленный ресурс закрывается, даже если предыдущий close() бросил исключение, — этот сбой не теряется, а записывается в пробрасываемое исключение как подавленный.

Он объявляет один или несколько ресурсов в скобках после try, и JVM закрывает их автоматически в конце блока — в порядке, обратном открытию — вызывая close() на каждом. Ресурс должен реализовывать AutoCloseable. Закрытие происходит и при нормальном выходе, и при исключении, поэтому finally для освобождения файлов или потоков не нужен. Если и тело, и close() бросают исключение, сбой close() становится подавленным исключением.

Дайте своему типу конструктор (String, Throwable), который передаёт аргументы в super(message, cause), и перебросьте через throw new UserLoadException(message, e);. Сам Throwable хранит эту причину, поэтому getCause() вернёт SQLException, а printStackTrace напечатает его кадры под Caused by:. Передача одного лишь e.getMessage() в конструктор только с сообщением сохраняет текст и молча выбрасывает исходный стектрейс.

Если тело try бросило исключение и при раскрутке блока close() тоже бросил, наружу уходит исключение тела, а сбой close() прикрепляется к нему через addSuppressed(), а не подменяет его. Эти второстепенные сбои читаются обратно методом Throwable.getSuppressed(), а printStackTrace печатает их под заголовком Suppressed:. У рукописного try/finally обратная беда: исключение из finally подменяет исходное, и настоящая причина теряется.

Один блок catch может перечислить несколько типов исключений через | — catch (IOException | SQLException e), — чтобы общее тело обработчика было написано один раз, а не скопировано под каждый тип. Перечисленные типы не должны быть связаны наследованием друг с другом: catch (IOException | FileNotFoundException e) — ошибка компиляции. Параметр неявно final, а его статический тип — ближайший общий надтип перечисленных вариантов.

Практически никогда. Error помечает сбой уровня JVM, от которого приложение не предполагает восстанавливаться: после OutOfMemoryError или StackOverflowError куча или стек уже повреждены, поэтому обработчик, который продолжает работу, опирается на состояние, которому нельзя доверять. Узкие законные случаи — обработчик верхнего уровня, который логирует и завершает процесс, и фреймворк, изолирующий одну задачу. Настоящая опасность — catch (Throwable t) в обычном коде: он молча глотает любой Error.

Дайте домену небольшую непроверяемую иерархию — AppException с NotFoundException и ConflictException — и переводите на каждой границе. Репозиторий ловит SQLException и перебрасывает доменный тип с оригиналом в качестве причины, поэтому ошибка базы всё равно доходит до лога под Caused by:. Контроллер отображает доменные типы в 404/409/500 и никогда не видит SQLException, и HTTP не протекает в нижние слои. Слой, который не может ничего сделать со сбоем, пропускает его дальше, а не глотает.

Проверяемые исключения дают контракт, проверяемый компилятором, но они не композируются: проверяемый тип заражает сигнатуру каждого вызывающего, не может покинуть лямбду в Stream.map (функциональные интерфейсы не объявляют throws), а добавление такого типа в минорном релизе ломает совместимость исходников. Это давление и порождает два антипаттерна — пустой catch (Exception e) и огульный throws Exception. Политика: по умолчанию непроверяемые, проверяемые — лишь там, где вызывающий реально может восстановиться.

Основная стоимость — fillInStackTrace, выполняемый при конструировании исключения: он обходит стек вызовов, чтобы захватить каждый кадр, что куда дороже ветвления. Поэтому замена if-проверки на null на перехват NullPointerException работает на порядки медленнее под нагрузкой и затемняет намерение. Если трейс реально не нужен, можно переопределить fillInStackTrace или использовать -XX:-StackTraceInThrowable, но настоящее решение — проверять условия явно.

finalize() был хуком в Object, который сборщик мусора вызывал перед освобождением объекта для последней очистки. Он не рекомендуется, потому что сборка мусора запускает его недетерминированно — возможно, никогда, — замедляет сборку, может воскресить объект, утекая this, и скрывает выброшенные им исключения. С Java 9 он устарел и заменён try-with-resources для детерминированного освобождения и Cleaner для подстраховки.

Сначала чините молчаливые сбои: пустой catch и голый printStackTrace одинаково теряют ошибку, поэтому каждый становится пробросом с логированием или прокомментированным решением проигнорировать. Затем восстанавливайте причины — передавайте пойманное исключение в конструктор BillingException: без причины инцидент нераскрываем. И только потом сужайте throws Exception по одному методу, чтобы вызывающие продолжали компилироваться. Доказывайте тестами на тип исключения и его причину, а не на факт падения вызова.