Обработка исключений в Java

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору

Сначала — общая теория

Перед этой главой: Ошибки, исключения и отказоустойчивость — ошибка vs исключение, раскрутка стека, когда использовать коды возврата.
В Java: Exception — обрабатываемые отклонения; Error — фатальные сбои JVM (OutOfMemoryError и др.), их обычно не "лечат" catch в бизнес-коде.

Исключения

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

Что такое исключение?

Исключение — это событие, нарушающее стандартный порядок выполнения инструкций в программе. В отличие от ошибок, обнаруживаемых ещё на этапе компиляции, исключения возникают во время выполнения и требуют специальных средств для реакции на них. В Java каждое исключение представлено объектом, принадлежащим к иерархии наследования, корнем которой является класс java.lang.Throwable.

Важно подчеркнуть, что термин "исключение" в данном контексте не означает нечто редкое или нежелательное в смысле "аварии"; скорее, это предсказуемое отклонение от ожидаемого поведения, которое может и должно быть учтено при проектировании программы. Даже при идеально написанном коде невозможно полностью исключить влияние внешних факторов — отсутствие файла на диске, временный сбой сети, истечение времени ожидания ответа от сервера. Именно для таких случаев и существует развитая модель исключений.

Механизм исключений в Java реализует стратегию передачи управления: при возникновении исключения интерпретатор или виртуальная машина (JVM) ищет ближайший обработчик — конструкцию, способную принять и корректно отреагировать на событие. Если обработчик не найден, программа завершается аварийно (аварийное завершение — сигнал разработчику и системе о том, что ситуация не была учтена). Таким образом, исключения — это средство реагирования на сбои и важный элемент проектирования: они формализуют контракты между компонентами и делают поведение системы прозрачным.

Интерактивное демо — часть сценариев на Python (try / except); в Java синтаксис свой, но стек вызовов и раскрутка те же. Подробнее: ошибки и исключения.

Play ITЗагрузка интерактивного демо…

Теория — обработка исключений

JVM реализует структурную обработку: при throw выполняется раскрутка стека до первого подходящего catch; на каждом уровне вызываются блоки очистки (finally, try-with-resources). Проверяемые исключения (IOException и др.) компилятор заставляет объявить или перехватить — это контракт "внешний сбой возможен". Непроверяемые (RuntimeException) — ошибки логики и программные контракты.

Error (нехватка памяти, переполнение стека) обычно не перехватывают в прикладном коде. Необработанное исключение ведёт к аварийному завершению потока или приложения. Подробнее — ошибки и исключения, иерархия типов — Иерархия классов исключений в Java.

Иерархия исключений в Java

Все исключения в Java являются наследниками класса Throwable. Этот класс — абстрактный корень всей иерархии, но непосредственно не используется в прикладном коде. От Throwable наследуются два основных подкласса:

java.lang.Error
java.lang.Exception

Это разделение отражает фундаментальный принцип проектирования: не все нарушения выполнения равнозначны с точки зрения возможности и целесообразности восстановления. Разберём оба направления.

`Error` — системные сбои, не подлежащие обработке

Класс Error и его подклассы обозначают серьёзные нарушения, как правило, связанные с состоянием виртуальной машины Java или среды выполнения. Такие события считаются неконтролируемыми с точки зрения прикладной логики — они сигнализируют о критических условиях, при которых корректное продолжение работы приложения невозможно или бессмысленно.

Примеры:

OutOfMemoryError — попытка выделения памяти превышает доступный объём кучи;
StackOverflowError — переполнение стека вызовов, вызванное, например, бесконечной рекурсией;
NoClassDefFoundError — класс, необходимый для выполнения, отсутствует в classpath во время исполнения (хотя был виден во время компиляции);
VirtualMachineError — обобщённая ошибка, указывающая на внутреннюю нестабильность JVM.

Важно: согласно рекомендациям Oracle и практике промышленной разработки, перехватывать экземпляры Error не следует. Попытка "восстановиться" после таких событий почти всегда приводит к неопределённому поведению — состояние JVM может быть нарушено, данные — повреждены, а сама попытка обработки лишь скроет проблему и затруднит диагностику. Вместо этого такие ситуации должны решаться на инфраструктурном уровне — мониторинг потребления памяти, настройка лимитов стека, проверка сборки и развёртывания.

`Exception` — исключения, доступные для программной обработки

Этот класс является базовым для всех обрабатываемых исключений — тех, с которыми приложение может и должно взаимодействовать. От Exception отходят два ключевых направления:

Проверяемые исключения (checked exceptions) — подклассы Exception, не являющиеся потомками RuntimeException.
Непроверяемые исключения (unchecked exceptions) — подклассы RuntimeException.

Проверяемые компилятор заставляет вас обработать (try-catch) или объявить (throws), а непроверяемые — нет.

Это разделение имеет не просто семантическое, но и компиляторное значение: Java требует явного учёта проверяемых исключений уже на этапе компиляции. Подобный подход основан на философии "errors should never pass silently" — если операция потенциально может завершиться неудачей по причинам, внешним по отношению к логике программы (например, ошибка ввода-вывода), разработчик обязан это предусмотреть.

Проверяемые исключения (`checked exceptions`)

Проверяемые исключения — это исключения, которые компилятор обязывает учитывать. Если метод может сгенерировать такое исключение, его сигнатура должна либо включать объявление throws соответствующего типа, либо содержать конструкцию try-catch, перехватывающую это исключение (или его предка). Это требование распространяется рекурсивно — если метод A вызывает метод B, который объявляет throws IOException, то A сам обязан либо обработать IOException, либо объявить его в своём throws.

Типичные представители:

IOException и его подклассы (FileNotFoundException, EOFException) — ошибки, связанные с операциями ввода-вывода;
SQLException — ошибки взаимодействия с базой данных через JDBC;
InterruptedException — уведомление о том, что поток был прерван во время ожидания;
ClassNotFoundException — попытка загрузки класса по имени, которого нет в classpath во время выполнения (в отличие от NoClassDefFoundError, это событие обрабатываемо, так как часто возникает в динамических сценариях, например, при использовании рефлексии или плагинов).

Пример:

public String readFirstLine(String path) throws IOException {
    try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
        return reader.readLine();
    }
    // reader.close() вызовется автоматически благодаря try-with-resources
}

Разбор:

Сигнатура throws IOException явно поднимает ответственность за реакцию на сбой на уровень вызывающего кода.
try ( ... ) включает автоматическое закрытие BufferedReader даже при ошибке в теле блока.
BufferedReader уменьшает число системных чтений за счет буфера, а FileReader открывает текстовый поток по пути.
return reader.readLine() извлекает только первую строку, поэтому метод фокусируется на одной четкой задаче.
Такая реализация формирует прозрачный API-контракт и не скрывает причину ошибки.

Здесь метод не гарантирует успешного чтения — файл может отсутствовать, быть заблокирован, содержать недопустимые символы и т.п. Вместо того чтобы "проглатывать" ошибку или аварийно завершаться, он честно декларирует: "Я могу столкнуться с IOException; решайте, что делать дальше". Это повышает предсказуемость API и заставляет вызывающий код принимать осознанное решение.

Непроверяемые исключения (`unchecked exceptions`)

Непроверяемые исключения — потомки java.lang.RuntimeException. Компилятор не требует их явной обработки или объявления в throws. Это означает, что метод может выбросить NullPointerException, IllegalArgumentException или ArrayIndexOutOfBoundsException, и при этом успешно скомпилироваться без каких-либо дополнительных аннотаций.

Ключевое различие — природа возникновения. Проверяемые исключения описывают ситуации, которые могут произойти даже при корректной программе — недоступность сервера, некорректный пользовательский ввод, отказ устройства. Непроверяемые же, напротив, почти всегда указывают на дефект в коде — обращение к null, выход за границы массива, деление на ноль, нарушение контракта (например, передача null туда, где он запрещён).

Примеры:

NullPointerException — попытка вызвать метод или получить доступ к полю у ссылки null;
ArrayIndexOutOfBoundsException — обращение к элементу массива по индексу, выходящему за [0, length-1];
ArithmeticException — арифметическая ошибка, например, деление целого числа на ноль;
IllegalArgumentException — передача аргумента, нарушающего логические ограничения метода (например, отрицательная длина списка);
IllegalStateException — попытка выполнить операцию в состоянии объекта, когда это недопустимо (например, вызов next() у итератора после hasNext() == false).

Хотя RuntimeException можно перехватывать, делать это повсеместно не рекомендуется. Это нарушает принцип "fail fast": лучше позволить программе упасть с понятным стек-трейсом, чем скрыть логическую ошибку и продолжать работу в неконсистентном состоянии. Вместо обработки RuntimeException следует предотвращать их возникновение — валидировать входные данные, использовать Optional, применять аннотации @NonNull, проводить unit-тестирование.

Однако существуют обоснованные случаи перехвата RuntimeException. Например, при интеграции с унаследованным кодом, когда нельзя гарантировать соблюдение контрактов, или на границе систем (например, веб-контроллер), где требуется преобразовать внутреннюю ошибку в понятный HTTP-ответ. Здесь важно — никогда не перехватывать "всё подряд" — catch (Exception e) или, хуже того, catch (Throwable t) — признак плохого дизайна.

Обработка исключений — механизмы и стратегии

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

Блок `try-catch-finally`

Классическая конструкция для локализованной обработки исключений. Структура:

try {
    // Код, потенциально выбрасывающий исключение
} catch (SpecificExceptionType e) {
    // Реакция на конкретный тип
} catch (AnotherExceptionType e) {
    // Реакция на другой тип
} finally {
    // Код, выполняемый независимо от результата try-блока
}

Каждый catch может обрабатывать только один тип исключения или его подтипы. Начиная с Java 7, допускается multi-catch: catch (IOException | SQLException e). Блоки catch проверяются сверху вниз, и выполняется первый, совместимый с типом выброшенного объекта — поэтому более специфичные исключения следует размещать раньше общих.

Блок finally выполняется всегда — независимо от того, было ли исключение выброшено, перехвачено или даже если в try или catch присутствует return, break или continue. Единственные исключения — системные события: завершение JVM (System.exit()), сбой питания или аппаратный сбой. Основная цель finally — обеспечить гарантированное освобождение ресурсов — закрытие файловых дескрипторов, соединений с базой данных, сетевых сокетов, освобождение блокировок.

Однако из-за сложности и потенциальных ошибок (например, выброс нового исключения в finally, которое перекроет оригинальное) современные практики предпочитают более безопасную альтернативу — try-with-resources.

Конструкция `try-with-resources`

Появившаяся в Java 7, эта форма try автоматизирует управление ресурсами, реализующими интерфейс java.lang.AutoCloseable (который, в свою очередь, наследуется java.io.Closeable). Ресурсы объявляются в скобках сразу после try, и JVM гарантирует их корректное закрытие по завершении блока — даже при возникновении исключения.

Пример:

try (FileInputStream fis = new FileInputStream("input.dat");
     BufferedInputStream bis = new BufferedInputStream(fis);
     OutputStreamWriter writer = new OutputStreamWriter(System.out)) {

    int b;
    while ((b = bis.read()) != -1) {
        writer.write(b);
    }
} catch (IOException e) {
    System.err.println("Ошибка при копировании: " + e.getMessage());
}
// Все три ресурса закрыты автоматически. Порядок: в обратном порядке объявления.

Разбор:

В заголовке try объявлены три ресурса, и каждый из них реализует AutoCloseable.
bis.read() возвращает -1 при завершении потока, поэтому цикл корректно определяет конец файла.
writer.write(b) записывает считанный байт в поток вывода и сохраняет исходный порядок данных.
При выходе из блока JVM закроет ресурсы автоматически в обратном порядке — writer, bis, fis.
Подход убирает ручной finally и снижает риск утечки дескрипторов.

Преимущества:

Повышение надёжности: ресурсы не "утекают", даже если в теле try произойдёт исключение.
Сокращение шаблонного кода: не нужно вручную писать finally и проверять != null.
Поддержка подавления исключений (suppressed exceptions) — если при закрытии ресурса возникнет IOException, он будет прикреплён к основному исключению как подавленное, и не потерян.

Важно: ресурс должен быть финализируемым — т.е. его объявление должно быть в форме Type var = expression. Локальные переменные или поля класса не подходят.

Декларативная передача — `throws`

Ключевое слово throws в сигнатуре метода указывает, что метод может сгенерировать исключение соответствующего типа. Это не означает, что исключение обязательно произойдёт; речь идёт о потенциальной возможности. Это механизм делегирования ответственности: метод говорит: "Я не беру на себя обработку этой проблемы — это задача вызывающего кода".

Такой подход особенно полезен при проектировании иерархий вызовов. Например, слой бизнес-логики может не знать, как реагировать на SQLException, но он может передать его слою инфраструктуры, где есть соответствующий обработчик (например, транзакционный менеджер, выполняющий откат). Однако злоупотребление throws ведёт к "загрязнению" API: если почти каждый метод объявляет throws Exception, это лишает сигнатуры смысла и затрудняет понимание контракта.

Правило хорошего тона: используйте throws только для семантически значимых исключений, которые являются частью контракта компонента. Не передавайте технические детали (например, SQLException) выше уровня доступа к данным — лучше обернуть их в доменные исключения (CustomerNotFoundException, PaymentProcessingFailedException).

Создание пользовательских исключений

Java позволяет разработчику определять собственные классы исключений. Это важный инструмент повышения выразительности и типобезопасности системы. Пользовательское исключение — это обычный класс, наследующий либо Exception, либо RuntimeException (в зависимости от того, планируется ли его как проверяемое или непроверяемое), и, как правило, содержащий:

Конструкторы, принимающие сообщение и/или причину (cause);
Дополнительные поля для контекста (например, идентификатор сущности, код ошибки);
Логику для генерации понятного сообщения (переопределение getMessage()).

Пример доменного исключения:

Код ITЗагрузка примера кода…

Такой подход позволяет:

Чётко отделять доменные ошибки от технических;
Обеспечивать типизированный catch (например, catch (InsufficientFundsException e) в контроллере);
Собирать метрики и логи с контекстом;
Формировать пользовательские сообщения без раскрытия внутренних деталей.

Рекомендация: при создании проверяемого пользовательского исключения наследуйтесь от Exception; при создании непроверяемого — от RuntimeException. Выбор зависит от семантики — если исключение отражает нарушение контракта (например, передача отрицательного баланса), выбирайте RuntimeException. Если оно описывает потенциально ожидаемое состояние (например, "пользователь не активировал аккаунт"), можно рассмотреть Exception.

Лучшие практики работы с исключениями

Не игнорируйте исключения. Пустой catch — один из самых опасных анти-паттернов. Даже если вы решаете "проглотить" исключение, обязательно оставьте комментарий с обоснованием — и лучше зафиксируйте факт в логе (на уровне DEBUG или TRACE).
Логируйте исключения с контекстом. При логировании используйте полный стек-трейс (logger.error("...", e)), а не только e.getMessage(). Добавляйте параметры вызова, идентификаторы сессий, временные метки.
Не раскрывайте внутренние детали в UI. Никогда не показывайте пользователю e.toString() или стек-трейс. Преобразуйте техническое исключение в понятное сообщение: "Не удалось сохранить документ. Проверьте подключение к серверу" вместо java.net.SocketTimeoutException: Read timed out.
Исключения — не механизм управления потоком. Не используйте throw и catch вместо if, return или циклов. Это снижает производительность (создание стек-трейса — дорогая операция) и ухудшает читаемость.
Преобразуйте исключения на границах слоёв. При переходе из одного подсистемы в другую (например, из DAL в сервисный слой) оборачивайте технические исключения в доменные. Это изолирует зависимости и упрощает тестирование.
Используйте try-with-resources везде, где возможно. Это стандарт де-факто для работы с ресурсами в современном Java-коде.
Тестируйте обработку исключений. Unit-тесты должны проверять как штатные сценарии, так и аварийные. Используйте assertThrows, ExpectedException (в JUnit 4) или assertThatExceptionOfType.

Исключения в контексте многопоточности

Многопоточное выполнение вносит дополнительную сложность в управление исключениями, поскольку потоки исполняются независимо, и аварийное завершение одного из них не останавливает другие. Если исключение, выброшенное в потоке, остаётся неперехваченным, по умолчанию JVM вызывает метод uncaughtException() у зарегистрированного UncaughtExceptionHandler, а затем завершает поток. Сама программа при этом может продолжать работу — что создаёт риски — утечки ресурсов, неконсистентные состояния, "тихие" сбои.

Глобальный и поток-локальный обработчики

Каждый объект Thread может иметь собственный UncaughtExceptionHandler, устанавливаемый через setUncaughtExceptionHandler(). Если он не задан, используется глобальный обработчик, определяемый через Thread.setDefaultUncaughtExceptionHandler(). Обработчик имеет единственный метод:

void uncaughtException(Thread t, Throwable e);

Разбор:

Это контракт обработчика необработанных исключений на уровне потока.
Thread t указывает, в каком именно потоке произошел сбой.
Throwable e передает полную информацию об ошибке, включая стек вызовов.
Метод вызывается JVM, когда исключение вышло из run() без локального catch.

Пример регистрации глобального обработчика:

Thread.setDefaultUncaughtExceptionHandler((thread, ex) -> {
    logger.error("Необработанное исключение в потоке {}", thread.getName(), ex);
    // Здесь можно инициировать graceful shutdown, отправить сигнал мониторингу и т.п.
});

Разбор:

setDefaultUncaughtExceptionHandler регистрирует единый fallback-обработчик для всех потоков без собственного handler.
Лямбда сохраняет имя потока и stack trace через logger.error(..., ex), что важно для диагностики.
Такой обработчик помогает обнаруживать фоновые ошибки, которые иначе остаются незаметными.
Здесь же удобно запускать технические реакции — алертинг, метрики, graceful shutdown.

Этот механизм особенно важен при использовании пулов потоков (ExecutorService), где потоки переиспользуются, и неперехваченное исключение может оставить задание в подвешенном состоянии (например, Future.get() будет ждать вечно). В таких случаях рекомендуется:

Явно оборачивать runnable/callable в try-catch;
Использовать CompletableFuture.exceptionally() или handle() при асинхронном программировании;
Настраивать ThreadFactory в пуле потоков так, чтобы каждый создаваемый поток имел собственный обработчик.

Важный нюанс: в JavaFX, Swing и Android действуют другие правила — исключения в UI-потоке должны обрабатываться в рамках фреймворка (например, Platform.runLater() в JavaFX перехватывает RuntimeException, но не Error).

Альтернативные стратегии

Хотя механизм исключений в Java мощен и удобен, он не является универсальным решением для всех ситуаций. Иногда более уместны подходы, основанные на возвращаемых значениях с явным указанием успеха или неудачи.

`Optional<T>`: для отсутствующих, но ожидаемых значений

Класс java.util.Optional<T>, появившийся в Java 8, предназначен для представления потенциально отсутствующего значения. Он особенно полезен, когда отсутствие результата — это нормальный, а не исключительный случай.

Сравните два подхода:

// Антипаттерн: возврат null
public User findUserById(long id) {
    // ... поиск в БД
    return null; // если не найдено
}

// Правильно: Optional сигнализирует о возможности отсутствия
public Optional<User> findUserById(long id) {
    // ... поиск в БД
    return Optional.ofNullable(userFromDb);
}

Разбор:

Первый вариант с null оставляет неявный контракт и повышает риск NullPointerException.
Optional<User> делает отсутствие значения явной частью API.
Optional.ofNullable(...) безопасно кодирует оба состояния: объект найден или его нет.
Подход улучшает читаемость вызывающего кода и снижает число неявных ошибок.

Клиентский код:

Optional<User> userOpt = service.findUserById(123);
if (userOpt.isPresent()) {
    userOpt.get().sendNotification();
} else {
    logger.debug("Пользователь 123 не найден — это допустимо");
}

Разбор:

isPresent() отделяет успешный сценарий от отсутствия результата.
Ветка else документирует, что "не найден" в данном кейсе считается нормальным исходом.
Такой императивный стиль понятен и хорошо подходит для пошагового обучения.
В production-коде его часто заменяют на более короткие цепочки ifPresent/orElse....

Или функционально:

service.findUserById(123)
       .ifPresent(User::sendNotification);

Разбор:

ifPresent(...) вызывает действие только когда значение действительно присутствует.
User::sendNotification — method reference, компактная форма лямбда-выражения.
Код убирает явный if и делает намерение максимально кратким.
Такой стиль снижает объем шаблонных проверок.

Преимущества Optional:

Чётко выражает семантику: "значение может отсутствовать" — это часть контракта;
Принудительно заставляет вызывающий код обработать оба сценария;
Избегает NullPointerException, связанного с неожиданным null;
Упрощает композицию через map, flatMap, orElse, orElseThrow.

Однако Optional не следует использовать:

Как поле класса (нарушает сериализуемость, усложняет reflective access);
В параметрах методов ("optional hell" — void process(Optional<A> a, Optional<B> b, ...));
Для коллекций (лучше возвращать пустую коллекцию, чем Optional<Collection>).

Интересный приём: orElseThrow(Supplier<RuntimeException>) позволяет по требованию превратить отсутствие значения в исключение, сохраняя "ленивую" семантику:

User user = repository.findById(id)
                      .orElseThrow(() -> new UserNotFoundException("ID: " + id));

Разбор:

orElseThrow(...) превращает пустой Optional в доменное исключение, понятное бизнес-слою.
Лямбда срабатывает лениво: объект исключения создается только при отсутствии записи.
После этой строки user гарантированно инициализирован, что упрощает следующий код.
Подход делает инвариант метода явным и типобезопасным.

Здесь исключение создаётся только в случае необходимости — в отличие от throw new Exception() в теле метода.

Производительность и стоимость исключений

Несмотря на удобство, исключения в Java не бесплатны. Основная стоимость связана с операцией заполнения стек-трейса — при создании объекта Throwable JVM проходит по текущему стеку вызовов и сохраняет информацию о каждом фрейме (имя метода, номер строки, класс). Это требует времени и памяти, особенно при глубоких стеках.

Эмпирические оценки (на современных JVM, HotSpot, режим server):

Создание new Exception() без стек-трейса — ~10–50 нс (сравнимо с new Object());
Создание new Exception() со стек-трейсом — ~1–10 мкс (в 100–1000 раз дороже);
Бросок и перехват — дополнительно ~0.5–2 мкс (в зависимости от глубины поиска обработчика).

Это означает: исключения нельзя использовать как замену условным операторам в "горячих" участках кода. Например, парсинг CSV-файла миллионными строками с try { Integer.parseInt(s) } catch (NumberFormatException e) { … } будет на порядки медленнее, чем предварительная валидация через регулярное выражение или Character.isDigit().

Оптимизации

Throwable.fillInStackTrace() можно переопределить.
Для высокопроизводительных систем (например, игровые серверы, HFT) иногда создают исключения без стек-трейса:

   public class FastException extends Exception {
       @Override
       public synchronized Throwable fillInStackTrace() {
           return this; // не заполняем стек
       }
   }

Но это следует делать с осторожностью — диагностика становится сложнее.

Кэширование исключений.
Если одно и то же исключение выбрасывается многократно (например, IllegalArgumentException("Argument must not be null")), можно создать его один раз как static final:

   private static final IllegalArgumentException NULL_ARG = 
       new IllegalArgumentException("Argument must not be null");
   
   public void process(String s) {
       if (s == null) throw NULL_ARG; // но: теряем контекст вызова!
   }

Однако такой подход уничтожает информацию о месте вызова — стек-трейс будет указывать на строку инициализации константы, а не на реальную точку сбоя. Используйте только если контекст известен из логики (например, в DSL-валидаторах).

Использование ExceptionInInitializerError и AssertionError с осторожностью.
Эти исключения часто используются для внутренних проверок, но их выброс может привести к полной остановке загрузки класса. Предпочтительнее IllegalArgumentException или собственные RuntimeException.

Современные тенденции и эволюция модели

Модель исключений Java остаётся стабильной, но новые возможности языка и платформы влияют на её применение.

Project Loom и виртуальные потоки

С выходом Project Loom (Java 21+) появляются виртуальные потоки (lightweight threads, java.lang.VirtualThread), управляемые JVM, а не ОС. Это меняет подход к обработке исключений:

Виртуальные потоки создавать дёшево — теперь допустимо заводить поток на каждую задачу, а не пулить;
Однако UncaughtExceptionHandler по-прежнему работает на уровне платформенного потока (carrier thread), что требует аккуратной настройки;
Асинхронные вызовы (CompletableFuture, реактивные потоки) остаются предпочтительнее для I/O-bound задач, но Loom делает блокирующий стиль (с try-catch) конкурентоспособным.

Пример — сервис, обрабатывающий 10 000 HTTP-запросов, теперь может использовать простой блокирующий InputStream.read() с try-catch, не опасаясь исчерпания потоков. Обработка исключений становится проще — как в однопоточной программе.

Реактивное программирование и `Mono.error()`

В экосистеме Reactor (Flux, Mono) и Project Reactor исключения интегрируются в поток данных: Mono.error(new IOException()) создаёт поток, который сразу завершается ошибкой. Обработка происходит через операторы:

onErrorReturn() — вернуть запасное значение;
onErrorResume() — продолжить с другого Mono;
doOnError() — побочный эффект (логирование);
retry() — повторить операцию.

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

Частые ошибки и антипаттерны

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

1. "Бессмысленный" `catch`

try {
    Files.readAllBytes(path);
} catch (IOException e) {
    // ничего не делаем
}

Последствия — молчаливое игнорирование ошибки, возможная порча данных, невозможность диагностики.
Исправление: как минимум logger.warn("Failed to read {}", path, e);, или преобразование в доменное исключение.

2. Перехват "всего подряд"

try {
    businessLogic();
} catch (Exception e) {
    handleError(e);
}

Разбор:

catch (Exception e) перехватывает слишком широкий диапазон ошибок, включая программные дефекты.
Такая конструкция может замаскировать ошибки, которые должны быстро приводить к падению и исправлению.
Универсальный handleError(e) без типизации часто теряет семантику бизнес-сценария.
Практика лучше работает с узкими типами исключений, соответствующими конкретному риску.

Проблема — маскируются RuntimeException, которые должны приводить к падению (например, NullPointerException).
Исправление: перехватывать только ожидаемые типы — catch (BusinessValidationException | IOException e).

3. Потеря стек-трейса при оборачивании

try {
    dao.save(user);
} catch (SQLException e) {
    throw new ServiceException("Save failed"); // теряем причину!
}

Разбор:

Исходный SQLException теряется, потому что новый ServiceException создается без cause.
В логах останется только верхнеуровневое сообщение, а корневая причина станет непрозрачной.
Такой код усложняет расследование инцидентов и увеличивает время восстановления.
Корректный wrapping должен сохранять цепочку исключений вторым параметром конструктора.

Правильно:

throw new ServiceException("Save failed for user " + user.getId(), e);

Разбор:

Второй аргумент e сохраняет первопричину через механизм cause.
Контекст user.getId() делает сообщение диагностически полезным для поддержки.
Такой шаблон соединяет бизнес-контекст и техническую причину в одной ошибке.
Формат соответствует хорошей практике передачи ошибок между слоями. — передаём cause, чтобы сохранить цепочку.

4. Закрытие ресурсов вручную

FileReader reader = null;
try {
    reader = new FileReader(path);
    // ...
} finally {
    if (reader != null) {
        try {
            reader.close();
        } catch (IOException ignored) { }
    }
}

Разбор:

Пример показывает старый ручной паттерн управления ресурсом через finally.
Код получается многословным и легко ломается при доработках.
ignored в catch скрывает возможную проблему закрытия и ухудшает наблюдаемость.
Современный try-with-resources делает ту же задачу короче и надежнее.

Это шаблонный, многострочный, подверженный ошибкам код.
Исправление: try (FileReader reader = new FileReader(path)) { … }

5. Использование исключений для управления потоком

for (;;) {
    try {
        return cache.get(key);
    } catch (CacheMissException e) {
        computeAndStore(key);
    }
}

Разбор:

Исключение CacheMissException здесь используется как обычная управляющая ветка.
Частый throw/catch в штатном пути нагружает CPU из-за формирования stack trace.
Чтение такого цикла сложнее, потому что нормальный сценарий спрятан в catch.
Для cache miss лучше применять явную проверку без исключений.

Гораздо эффективнее:

Value v = cache.getOrNull(key);
if (v == null) {
    v = computeAndStore(key);
}
return v;

Разбор:

getOrNull(key) выражает отсутствие значения как ожидаемый результат, а не аварийное событие.
if (v == null) явно запускает вычисление и заполнение кэша.
Логика становится линейной, предсказуемой и проще покрывается тестами.
Такой вариант обычно быстрее и лучше масштабируется на нагруженных сервисах.

Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.

Исключения​

Что такое исключение?​

Иерархия исключений в Java​

Error — системные сбои, не подлежащие обработке​

Exception — исключения, доступные для программной обработки​

Проверяемые исключения (checked exceptions)​

Непроверяемые исключения (unchecked exceptions)​

Обработка исключений — механизмы и стратегии​

Блок try-catch-finally​

Конструкция try-with-resources​

Декларативная передача — throws​

Создание пользовательских исключений​

Лучшие практики работы с исключениями​

Исключения в контексте многопоточности​

Глобальный и поток-локальный обработчики​

Альтернативные стратегии​

Optional<T>: для отсутствующих, но ожидаемых значений​

Производительность и стоимость исключений​

Оптимизации​

Современные тенденции и эволюция модели​

Project Loom и виртуальные потоки​

Реактивное программирование и Mono.error()​

Частые ошибки и антипаттерны​

1. "Бессмысленный" catch​

2. Перехват "всего подряд"​

3. Потеря стек-трейса при оборачивании​

4. Закрытие ресурсов вручную​

5. Использование исключений для управления потоком​

См. также

JaОсновы языка Java

JaЧто требуется знать перед началом изучения языка программирования Java

JaРекомендации по разработке на Java

JaВвод и вывод в Java

JaIntelliJ IDEA — IDE для разработки на Java

JaИстория языка Java

JaЭкосистема Java-приложений

JaСтруктура и сборки Java-проектов

JaСправочник по конфигурациям в Java

JaПервая программа на Java

JaПростые приложения на Java

JaОтладка Java-кода в IDE

Исключения

Что такое исключение?

Иерархия исключений в Java

`Error` — системные сбои, не подлежащие обработке

`Exception` — исключения, доступные для программной обработки

Проверяемые исключения (`checked exceptions`)

Непроверяемые исключения (`unchecked exceptions`)

Обработка исключений — механизмы и стратегии

Блок `try-catch-finally`

Конструкция `try-with-resources`

Декларативная передача — `throws`

Создание пользовательских исключений

Лучшие практики работы с исключениями

Исключения в контексте многопоточности

Глобальный и поток-локальный обработчики

Альтернативные стратегии

`Optional<T>`: для отсутствующих, но ожидаемых значений

Производительность и стоимость исключений

Оптимизации

Современные тенденции и эволюция модели

Project Loom и виртуальные потоки

Реактивное программирование и `Mono.error()`

Частые ошибки и антипаттерны

1. "Бессмысленный" `catch`

2. Перехват "всего подряд"

3. Потеря стек-трейса при оборачивании

4. Закрытие ресурсов вручную

5. Использование исключений для управления потоком

Основы языка Java

Что требуется знать перед началом изучения языка программирования Java

Рекомендации по разработке на Java

Ввод и вывод в Java

IntelliJ IDEA — IDE для разработки на Java

История языка Java

Экосистема Java-приложений

Структура и сборки Java-проектов

Справочник по конфигурациям в Java

Первая программа на Java

Простые приложения на Java

Отладка Java-кода в IDE