5.03. Исключения

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

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

Исключения

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

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

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

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

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

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

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

• java.lang.Error
• java.lang.Exception

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

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

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

Примеры:

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

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

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

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

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

Это разделение имеет не просто семантическое, но и компиляторное значение: 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
}

Здесь метод не гарантирует успешного чтения: файл может отсутствовать, быть заблокирован, содержать недопустимые символы и т.п. Вместо того чтобы «проглатывать» ошибку или аварийно завершаться, он честно декларирует: «Я могу столкнуться с 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 data;
    while ((data = bis.read()) != -1) {
        writer.write(data);
    }
} catch (IOException e) {
    System.err.println("Ошибка при копировании: " + e.getMessage());
}
// Все три ресурса закрыты автоматически. Порядок: в обратном порядке объявления.

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

• Повышение надёжности: ресурсы не «утекают», даже если в теле 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()).

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

public class InsufficientFundsException extends RuntimeException {
    private final String accountId;
    private final BigDecimal requiredAmount;
    private final BigDecimal availableBalance;

    public InsufficientFundsException(String accountId, BigDecimal required, BigDecimal available) {
        super("Недостаточно средств на счёте " + accountId +
              ". Требуется: " + required + ", доступно: " + available);
        this.accountId = accountId;
        this.requiredAmount = required;
        this.availableBalance = available;
    }

    // Геттеры для логирования, телеметрии, формирования UI-сообщений
    public String getAccountId() { return accountId; }
    public BigDecimal getRequiredAmount() { return requiredAmount; }
    public BigDecimal getAvailableBalance() { return availableBalance; }
}

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

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

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

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

1. Не игнорируйте исключения. Пустой catch — один из самых опасных анти-паттернов. Даже если вы решаете «проглотить» исключение, обязательно оставьте комментарий с обоснованием — и лучше зафиксируйте факт в логе (на уровне DEBUG или TRACE).

2. Логируйте исключения с контекстом. При логировании используйте полный стек-трейс (logger.error("...", e)), а не только e.getMessage(). Добавляйте параметры вызова, идентификаторы сессий, временные метки.

3. Не раскрывайте внутренние детали в UI. Никогда не показывайте пользователю e.toString() или стек-трейс. Преобразуйте техническое исключение в понятное сообщение: «Не удалось сохранить документ. Проверьте подключение к серверу» вместо java.net.SocketTimeoutException: Read timed out.

4. Исключения — не механизм управления потоком. Не используйте throw и catch вместо if, return или циклов. Это снижает производительность (создание стек-трейса — дорогая операция) и ухудшает читаемость.

5. Преобразуйте исключения на границах слоёв. При переходе из одного подсистемы в другую (например, из DAL в сервисный слой) оборачивайте технические исключения в доменные. Это изолирует зависимости и упрощает тестирование.

6. Используйте try-with-resources везде, где возможно. Это стандарт де-факто для работы с ресурсами в современном Java-коде.

7. Тестируйте обработку исключений. Unit-тесты должны проверять как штатные сценарии, так и аварийные. Используйте assertThrows, ExpectedException (в JUnit 4) или assertThatExceptionOfType.

---

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

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

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

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

void uncaughtException(Thread t, Throwable e);

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

Thread.setDefaultUncaughtExceptionHandler((thread, ex) -> {
    logger.error("Необработанное исключение в потоке {}", thread.getName(), 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);
}

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

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

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

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

Преимущества 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));

Здесь исключение создаётся только в случае необходимости — в отличие от 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().

Оптимизации

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

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

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

2. Кэширование исключений.
   Если одно и то же исключение выбрасывается многократно (например, 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-валидаторах).

3. Использование 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);
}

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

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

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

Правильно:

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

— передаём cause, чтобы сохранить цепочку.

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

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

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

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

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

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

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

---