Краткий ответ

Компилятор требует явно обработать или пробросить дальше только проверяемое исключение — наследника Exception, который не является наследником RuntimeException. Для него вызывающий код должен использовать catch или добавить исключение в собственную сигнатуру через throws.

Непроверяемые исключения (RuntimeException и его наследники), а также Error не требуют такой обработки на этапе компиляции. Они всё равно могут распространяться по стеку вызовов и быть перехвачены явно.

Исторический контекст

Модель проверяемых исключений появилась как способ сделать потенциально восстанавливаемые ошибки частью контракта метода. Например, чтение файла может завершиться отсутствием файла или ошибкой доступа, поэтому вызывающий код должен осознанно выбрать обработку или передачу проблемы выше.

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

Постановка проблемы

Если разработчик не различает эти категории, он либо получает ошибки компиляции, либо создаёт ложное ощущение безопасности. Добавление throws RuntimeException не заставляет вызывающий код писать обработчик, а перехват общего Exception не гарантирует корректного восстановления после любой ошибки.

Неверное решение особенно опасно в API библиотек: изменение типа исключения может внезапно потребовать изменений во всех вызывающих методах. С другой стороны, превращение каждой ошибки в RuntimeException скрывает важные условия, которые клиент метода должен обработать явно.

Подробное решение

Компилятор анализирует исключения, которые могут выйти из тела метода, и проверяет их по иерархии. Проверяемым считается любой наследник Throwable, кроме RuntimeException и Error с их наследниками.

Для проверяемого исключения допустимы два варианта: перехватить его подходящим catch или объявить в сигнатуре текущего метода через throws. Если метод вызывает другой метод, объявляющий проверяемое исключение, это исключение должно быть обработано или также объявлено.

import java.io.IOException;

class Reader {
    static void load() throws IOException {
        throw new IOException("read failed");
    }

    static void process() throws IOException {
        load();
    }

    static void start() {
        try {
            process();
        } catch (IOException e) {
            System.out.println("fallback");
        }
    }
}

В примере process не обрабатывает IOException, поэтому явно пробрасывает его. Метод start завершает цепочку распространения обработчиком.

Для RuntimeException такого требования нет: компилятор не обязан перечислять все возможные ошибки вроде NullPointerException в сигнатуре. Однако объявление throws технически допускается и для непроверяемых исключений, хотя само по себе оно не создаёт обязательства для вызывающего кода.

Проверяемость определяется статическим типом исключения и правилами компилятора, а не тем, насколько ошибка кажется разработчику серьёзной. Один и тот же фактический сбой может стать проверяемым или непроверяемым в зависимости от типа, которым он представлен в API.

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

Ситуация из практики

Сервис загружает конфигурацию из файла. Низкоуровневый метод сообщает IOException, и команда рассматривает два варианта: заставить каждый слой обрабатывать это исключение или преобразовать его в собственное непроверяемое исключение.

Обработка на каждом уровне даёт явный контроль, но приводит к дублированию и связывает бизнес-слои с файловой системой. Простое преобразование в RuntimeException уменьшает количество шаблонного кода, но может скрыть понятную стратегию: использовать настройки по умолчанию, остановить запуск или сообщить администратору.

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

Что кандидаты часто упускают

1. Обязан ли метод обрабатывать проверяемое исключение, если оно указано в throws вызываемого метода, но фактически не возникает в конкретной ветке?

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

2. Можно ли перехватить RuntimeException и чем это отличается от обязательной обработки?

Можно: RuntimeException является обычным объектом-исключением и перехватывается через catch. Отличие в том, что компилятор не требует такого catch или throws; решение полностью остаётся за разработчиком. Перехватывать все непроверяемые исключения без чёткой стратегии опасно: это может скрыть дефекты и оставить приложение в неконсистентном состоянии.

3. Почему добавление проверяемого исключения в сигнатуру публичного метода является потенциально ломающим изменением?

Клиенты этого метода должны после изменения начать обрабатывать новое исключение или добавлять его в свои сигнатуры. Требование распространяется вверх по цепочке вызовов и может затронуть много исходного кода. Поэтому проверяемые исключения полезны для действительно значимых условий, но их следует выбирать как стабильную часть API-контракта, а не как отражение каждой внутренней детали реализации.