Почему не стоит глотать исключения (catch empty)

Это одна из самых опасных ошибок в программировании, потому что:

🟢 Junior Level

Краткий ответ для собеседования (30 секунд)

«Глотание» исключений (Exception Swallowing) — это антипаттерн, при котором исключение перехватывается в блоке catch, но никак не обрабатывается, не логируется и не пробрасывается дальше (catch (Exception e) {}).

Это одна из самых опасных ошибок в программировании, потому что:

Программа переходит в неконсистентное состояние: Метод аварийно прервался на середине выполнения, важные поля не проинициализировались, но вызывающий код уверен, что операция прошла успешно.
Исчезает первопричина аварии: В логах нет ни строчки. Сбой проявится гораздо позже в совершенно другом модуле, и расследовать его будет практически невозможно.
Бесполезная трата CPU: Виртуальная машина уже потратила ресурсы на нативный обход стека fillInStackTrace(), но результат вычисления был молча выброшен сборщику мусора.

Механика JVM: как теряется исключение

При возникновении ошибки JVM приостанавливает нормальный поток исполнения и ищет подходящий обработчик в таблице исключений метода (Exception_table). Когда управление передается в блок catch, исключение считается полностью обработанным. Если тело блока пустое:

JVM переходит к следующей инструкции байткода за пределами блока try-catch.
Объект исключения теряет ссылки и утилизируется сборщиком мусора (GC).
Все вышестоящие вызывающие методы остаются в неведении о произошедшей катастрофе.

// ❌ АНТИПАТТЕРН: катастрофическое повреждение данных
public void transferMoney(Account from, Account to, BigDecimal amount) {
    try {
        from.debit(amount);     // 1. Деньги списаны со счета
        saveAccount(from);
        
        to.credit(amount);      // 2. Бросает исключение (например, счет заблокирован)
        saveAccount(to);
    } catch (Exception e) {
        // ПУСТО! Исключение проглочено.
    }
    // Метод завершился "успешно". Деньги у клиента списались, но получателю не пришли!
}

🟡 Middle Level

Редкие исключения: когда пустой catch оправдан

Спецификация и статические анализаторы допускают подавление исключения в строго ограниченных сценариях:

1. Ожидаемое прерывание потока (`InterruptedException`)

При перехвате InterruptedException категорически запрещено оставлять блок пустым без восстановления флага прерывания, иначе внешние планировщики задач (например, ExecutorService) не смогут корректно остановить рабочий поток:

try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    // ОБЯЗАТЕЛЬНО восстанавливаем статус прерывания потока!
    Thread.currentThread().interrupt();
    log.warn("Task was interrupted during sleep");
}

2. Соглашение об именовании `ignored` (Java Convention)

Если исключение действительно ожидаемо и его игнорирование предусмотрено дизайном алгоритма, переменную называют ignored или expected. Это сигнализирует линтерам (IntelliJ, SonarQube), что действие совершено осознанно:

// Попытка закрыть устаревший сокет при аварийном завершении соединения
try {
    socket.close();
} catch (IOException ignored) {
    // Ничего нельзя сделать, соединение и так мертво
}

3. Необязательные побочные операции (Best-effort Actions)

Очистка временных файлов при остановке JVM или обновление локального кэша, отказ которого не ломает бизнес-логику:

try {
    metricsClient.sendHit("user.login");
} catch (MetricsException e) {
    // Падение сервиса метрик не должно ломать логин пользователя!
    // МИНИМУМ: логируем на уровне DEBUG для расследования
    log.debug("Failed to send metrics", e);
}

Катастрофа в Spring `@Transactional` и `UnexpectedRollbackException`

Если в методе, помеченном Spring-аннотацией @Transactional, возникает непроверяемое исключение, транзакционный аспект Spring перехватывает его и помечает текущую физическую транзакцию БД как Rollback-Only (setRollbackOnly()).

Если разработчик на уровне выше проглотит это исключение:

@Service
public class OrderService {

    @Autowired
    private PaymentService paymentService;

    @Transactional
    public void placeOrder(Order order) {
        try {
            paymentService.charge(order); // Метод падает с RuntimeException -> транзакция помечена Rollback-Only!
        } catch (RuntimeException e) {
            // Исключение проглочено! Разработчик думает, что всё под контролем.
        }
        // Метод placeOrder пытается закоммитить транзакцию...
        // КРАХ: Spring выбрасывает org.springframework.transaction.UnexpectedRollbackException!
    }
}

Результат: Коммит завершится фатальным UnexpectedRollbackException. Попытка скрыть ошибку через catch только усугубила проблему и привела к падению на этапе закрытия транзакции.

Проглатывание ошибок в Stream API и реактивных цепочках

Проглатывание исключений внутри функциональных потоков разрушает целостность данных:

// ❌ АНТИПАТТЕРН: возвращаем null вместо обработки
List<UserDto> users = userIds.stream()
    .map(id -> {
        try {
            return client.fetchUser(id);
        } catch (Exception e) {
            return null; // В коллекцию проникают скрытые null-элементы!
        }
    })
    .toList(); // Итоговый список содержит [User, null, User, null] -> NullPointerException ниже по коду

🔴 Senior Level

“Zombie Architecture” и скрытые сбои (Silent Corruption)

Проглатывание исключений порождает так называемые системы-зомби:

Процесс Java запущен, порт слушается, метрики /actuator/health отдают 200 OK.
Однако внутренний кэш рассинхронизирован с базой, события из Kafka перестали вычитываться, а фоновые планировщики зависли.
Потребуются недели, чтобы обнаружить финансовые расхождения, вызванные одной проглоченной строкой ошибки.

Стоимость скрытых исключений под высокой нагрузкой (Highload Penalty)

Некоторые разработчики полагают: «Если я ловлю исключение пустым catch, оно работает быстро, как пустой if». Это фундаментальное заблуждение.

Вызов метода
    │
    ▼
new CustomException() ──> JVM HotSpot переходит в нативный C++ код
                            │
                            ▼
                    fillInStackTrace() (обход стека фреймов потока ядра ОС)
                            │
                            ▼
                    Аллокация массива StackTraceElement[] в Heap
                            │
                            ▼
                    catch (Exception ignored) { } // Объект мгновенно брошен GC!

Если в цикле обработки 10 000 сообщений в секунду исключение регулярно выбрасывается и проглатывается:

Потребление процессора вырастает до 100% исключительно на раскрутку стеков.
Создается гигантское давление на Garbage Collector (GC Pressure) из-за миллиардов короткоживущих объектов исключений.
В логах при этом царит абсолютная тишина, делая профилирование крайне сложным без async-profiler.

Контроль качества кода в CI/CD: Quality Gates

В корпоративном пайплайне разработка защищается статическими анализаторами:

SonarQube Rule java:S1166: “Exception handlers should preserve the original exceptions”. Запрещает перехват без логирования или проброса.
SonarQube Rule java:S108: “Nested blocks of code should not be empty”.
Google Error-Prone: проверка EmptyCatch.

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

Вопросы для быстрой проверки

Что произойдет в Spring @Transactional, если проглотить RuntimeException в блоке catch вызывающего метода? Ответ: Транзакция все равно не закоммитится. Внутренний механизм Spring пометит транзакцию флагом rollback-only. При выходе из внешнего транзакционного метода Spring попытается зафиксировать транзакцию, обнаружит метку отката и выбросит UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only.
Почему при перехвате InterruptedException нельзя оставлять блок catch пустым? Ответ: При выбрасывании InterruptedException JVM автоматически сбрасывает статус прерывания текущего потока (isInterrupted() == false). Если не восстановить его вызовом Thread.currentThread().interrupt(), внешний пул потоков или координатор задач не узнает о сигнале завершения и поток продолжит бесконечно работать.
Почему проглатывание исключения в цикле высоконагруженного сервиса приводит к падению производительности? Ответ: Создание объекта исключения сопровождается нативным вызовом fillInStackTrace(), требующим приостановки исполнения и линейного обхода стека вызовов. Даже если исключение сразу проглочено, ресурсы CPU и памяти на сборку стека уже затрачены.
Какое соглашение об именовании используется в Java для переменных исключений, которые сознательно игнорируются? Ответ: Переменную называют словом ignored (например, catch (IOException ignored) {}). Это стандартизированный маркер для статических анализаторов (Sonar, IntelliJ IDEA), подтверждающий намеренное игнорирование ошибки.

Типичные ошибки и Red Flags

❌ Утверждение: “Если ошибка не важна, проще поставить пустой catch”: Приводит к скрытым багам и зомби-сервисам.
❌ Пустой catch (InterruptedException e) {}: Потеря сигнала завершения потока и зависание приложений при остановке контейнера.
❌ Проглатывание ошибок валидации в Stream API с возвратом null: Порождает отложенные NullPointerException в других модулях.
❌ Отсутствие даже log.debug() при осознанном игнорировании сбоя: Делает невозможной диагностику в production.