Junior Level

Да, можно!

Java позволяет использовать несколько catch блоков для одного try:

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.nio.file.FileNotFoundException;

public class FileProcessor {
    public String readFile(String path) {
        try {
            return Files.readString(Paths.get(path));
        } catch (FileNotFoundException e) {
            // Частный случай — файл не существует
            return "default content";
        } catch (IOException e) {
            // Более общий — другие IO ошибки
            throw new ServiceException("Failed to read file: " + path, e);
        }
    }
}

Правило: от частного к общему

Блоки catch должны идти от конкретных к общим:

// Правильно
try { ... }
catch (FileNotFoundException e) { }  // Частный
catch (IOException e) { }            // Более общий
catch (Exception e) { }              // Самый общий

// Неправильно — не скомпилируется!
try { ... }
catch (Exception e) { }              // Перехватит всё!
catch (FileNotFoundException e) { }  // Никогда не выполнится

ПОЧЕМУ порядок важен: механизм “first match wins”

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

На уровне компилятора:

1. Компилятор анализирует каждый catch блок сверху вниз.
2. Для каждого catch он проверяет: “Есть ли уже выше catch, который является супертипом текущего?”
3. Если да — ошибка компиляции "exception X has already been caught", потому что код в нижнем catch блоке недостижим (unreachable code, JLS 14.21).
4. Если нет — catch добавляется в Exception Table.

На уровне JVM (рантайм):

1. При выбросе исключения JVM проходит Exception Table сверху вниз.
2. Первое совпадение по типу (или супертипу) захватывает управление.
3. Остальные catch блоки не проверяются — даже если они тоже подошли бы.

Это называется “first match wins”. Поэтому порядок определяет, какой обработчик получит управление.

try { ... }
catch (FileNotFoundException e) { ... }  // #1: проверяется первым
catch (IOException e) { ... }             // #2: проверяется, только если #1 не подошёл

Если в try брошен FileNotFoundException, JVM найдёт совпадение в #1 и не дойдёт до #2, хотя FileNotFoundException также является IOException.

finally после всех catch

try {
    // код
} catch (IOException e) {
    // обработчик IO
} catch (Exception e) {
    // обработчик остальных
} finally {
    // Выполнится после любого catch
}

Когда НЕ использовать несколько catch блоков

1. Одинаковая обработка — если все catch блоки делают одно и то же, используйте multi-catch (A | B) — это короче и читаемее (Java 7+)
2. Более 5 catch блоков — признак нарушения SRP, метод делает слишком много. Рассмотрите разделение на несколько методов
3. Ловите Exception когда не важна специфика — для generic логирования одного catch достаточно
4. В функциональном стиле — вместо catch используйте Either/Try монады (Vavr library)
5. Когда достаточно @ControllerAdvice — в Spring REST один глобальный обработчик заменяет 10 catch блоков

Caveat: Java 7+ multi-catch как альтернатива

Начиная с Java 7, вместо нескольких отдельных catch блоков с одинаковой логикой можно использовать multi-catch:

// Вместо:
catch (IOException e) {
    log.error("Error", e);
    throw new ServiceException(e);
}
catch (SQLException e) {
    log.error("Error", e);
    throw new ServiceException(e);
}

// Пишем:
catch (IOException | SQLException e) {
    log.error("Error", e);
    throw new ServiceException(e);
}

Multi-catch предпочтительнее, когда обработка идентична. Раздельные catch нужны только когда логика различается (например, retry для IO, но не для SQL).

---

Middle Level

Как JVM ищет обработчик

В .class файле создаётся Exception Table:

from	to	target	type
0	10	13	FileNotFoundException
0	10	25	IOException
0	10	37	Exception

Когда происходит athrow, JVM сканирует таблицу сверху вниз до первого совпадения.

Антипаттерн: дублирование кода

// Плохо — дублирование
try { ... }
catch (IOException e) {
    log.error("Error", e);
    throw new ServiceException(e);
}
catch (SQLException e) {
    log.error("Error", e);       // То же самое!
    throw new ServiceException(e); // То же самое!
}

// Хорошо — multi-catch
try { ... }
catch (IOException | SQLException e) {
    log.error("Error", e);
    throw new ServiceException(e);
}

Разделение логики

Если нужна разная обработка — отдельные catch оправданы:

try {
    // код
} catch (FileNotFoundException e) {
    log.warn("File not found, using default");
    return getDefaultData();
} catch (IOException e) {
    log.error("IO error", e);
    throw new ServiceException(e);
}

Cost of Catch

Сама попытка входа в catch “бесплатна” до момента, пока исключение не выброшено. Наличие Exception Table не замедляет выполнение try блока.

---

Senior Level

Exception Table Size

Огромное количество catch блоков может раздуть размер метода за пределы 64КБ → ошибка компиляции. Это верный признак нарушения SRP — метод делает слишком много.

Polymorphism vs Catch

Вместо 10 catch блоков иногда лучше:

// Альтернатива — обработка через иерархию
catch (BusinessException e) {
    // Обработает все подтипы: OrderException, PaymentException, etc.
    handleBusinessError(e);
}

Или Pattern Matching (Java 17+):

catch (Exception e) {
    if (e instanceof FileNotFoundException fnf) {
        // fnf уже приведён к типу
    } else if (e instanceof IOException io) {
        // io уже приведён к типу
    }
}

Catching Error

Можно ловить Error или Throwable, но после OutOfMemoryError состояние приложения непредсказуемо. Ловить стоит только для “последнего вдоха” — логирования перед падением.

Диагностика

• javap -v MyClass.class — покажет реальную Exception Table
• Log Correlation — сохраняйте общие метаданные (Trace ID) для всех типов ошибок
• Static Analysis — Sonar предупреждает о дублировании в catch блоках
• Метрики — считайте каждый тип исключения через Micrometer

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Несколько catch блоков для одного try — разрешено и широко используется
• Правило: от частного к общему — FileNotFoundException перед IOException перед Exception
• Компилятор проверяет порядок на этапе компиляции — неправильный порядок = ошибка “already been caught”
• JVM ищет обработчик “first match wins” — проходит Exception Table сверху вниз до первого совпадения
• Наличие Exception Table не замедляет выполнение try блока — проверка “бесплатна” до исключения
• Если обработка идентична — используйте multi-catch (IOException | SQLException) вместо дублирования
• Более 5 catch блоков — признак нарушения SRP, метод делает слишком много

Частые уточняющие вопросы:

• Почему нельзя Exception перед IOException? — Exception перехватит всё, IOException станет недостижимым кодом
• Как JVM ищет обработчик? — Проходит Exception Table сверху вниз, первое совпадение захватывает управление
• Когда нужны раздельные catch, а не multi-catch? — Когда разная логика обработки (retry для IO, не для SQL)
• Влияет ли количество catch на производительность? — O(n) поиск в Exception Table, размещайте частые первыми

Красные флаги (НЕ говорить):

• “Ставлю catch (Exception e) первым для простоты” — не скомпилируется с более частными catch
• “Много catch блоков не влияют на производительность try” — верно, но влияют на поиск при исключении
• “Использую catch для Error в бизнес-логике” — после OutOfMemoryError состояние непредсказуемо
• “Дублирую код в каждом catch” — используйте multi-catch при идентичной обработке

Связанные темы:

• [[25. Что такое multi-catch (catching multiple exceptions)]] — альтернатива при одинаковой обработке
• [[26. В каком порядке располагать catch блоки]] — детальное объяснение ordering
• [[27. Можно ли повторно бросить исключение]] — rethrow из catch блока
• [[1. В чём разница между checked и unchecked exceptions]] — какие исключения ловить
• [[4. Какие исключения нужно обрабатывать обязательно]] — обязательные catch