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

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

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

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

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

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

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

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

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

После входа в catch исходное исключение доступно через его параметр. Если обработчик завершился новым throw, выполнение оставляет весь текущий try-catch; другие catch, относящиеся к этому же try, новое исключение не перехватывают. Поиск обработчика продолжается у вызывающего метода.

class Demo {
    static void load() throws Exception {
        try {
            throw new java.io.IOException("диск");
        } catch (java.io.IOException e) {
            throw new IllegalStateException("загрузка невозможна", e);
        }
    }

    public static void main(String[] args) {
        try {
            load();
        } catch (IllegalStateException e) {
            System.out.println(e.getCause().getClass().getSimpleName());
        }
    }
}

Здесь IllegalStateException становится основным исключением, а IOException сохраняется как его причина (cause). Поэтому верхний уровень может реагировать на новый абстрактный тип, не теряя техническую информацию для журналирования.

Если новое исключение создаётся без исходного объекта и без явного связывания, автоматического поля cause не появляется. Это отличается от подавленных исключений: они возникают в определённых сценариях управления ресурсами, а не просто из-за выброса нового исключения в catch.

Если в catch используется return, исходное исключение также не продолжает распространение: обработчик завершает текущий метод обычным возвратом. Однако finally, если он есть, всё равно выполняется и может изменить итог — например, выбросить собственное исключение.

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

Сервис читает файл конфигурации и не может устранить ошибку доступа. Возможны два варианта: пробросить IOException наружу или преобразовать её в ConfigurationException.

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

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

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

1. Может ли следующий catch того же try обработать исключение, выброшенное предыдущим catch?

Нет. После выбора подходящего catch остальные обработчики этого try больше не рассматриваются. Новое исключение ищет обработчик у внешнего try или в вызывающем коде.

2. Что произойдёт, если в catch выполнить return?

Метод подготовит обычный возврат, а исходное исключение перестанет распространяться. Перед фактическим выходом всё равно выполняется finally; если он выбросит исключение, оно заменит подготовленный результат и станет новым исходом метода.

3. Всегда ли при преобразовании исключения нужно сохранять исходное как cause?

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