Почему пустой catch опасен (кратко)
- Скрывает ошибки: баги и исключения остаются без следа — сложно отладить.
- Нарушает инварианты: состояние объекта/системы может остаться неконсистентным.
- Утечки ресурсов/трейсы: исключение могло помешать закрытию/откату.
- Прерывание контроля выполнения: программа продолжит работать в неизвестном состоянии.
- Безопасность и надёжность: приводит к непредсказуемому поведению и уязвимостям.
- Специальный кейс — InterruptedException: если его «съесть», теряется флаг прерывания потока.
Стратегии обработки ошибок (с кратким плюсом/минусом)
- Пробросить исключение (propagate)
- + Простота, fail-fast, сохраняется стек вызовов.
- - Требует, чтобы вызывающий код умел обрабатывать.
- Бросить обёртку с контекстом (wrap + rethrow)
- + Добавляет информацию (что, где), не теряет cause.
- - Нужно выбирать семантически подходящий тип исключения.
- Возврат кодов/значений результата (return codes, Result/Either)
- + Явный контракт, полезно для функционального стиля и API без исключений.
- - Неудобно в Java без алгебрических типов; можно забыть проверку.
- Объект-результат с ошибкой (Result, Either, Optional+error)
- + Явно показывает успех/ошибку, легко композиционно обрабатывать.
- - Требует дополнительной структуры/библиотеки.
- Суммирование/агрегация ошибок (collect & throw AggregateException)
- + Полезно при параллельных/множественных операциях, чтобы не терять другие ошибки.
- - Усложняет обработку, нужно агрегатор.
- Логирование + подавление (log-and-suppress)
- + Если ошибка не критична, оставляет след в логах.
- - Нужна тщательная логика: уровень, контекст, можно потерять в шуме.
- Ретрай / компенсация / фолбек
- + Повышает устойчивость при временных отказах.
- - Нужно ограничить число повторов и учитывать идемпотентность.
Практические правила
- Не ловите Exception/Throwable без необходимости; ловите конкретные типы.
- Если не можете обработать — пробросьте (или оберните и бросьте).
- Всегда логируйте достаточный контекст (сообщение + stack trace).
- Для InterruptedException — восстановите флаг: Thread.currentThread().interrupt();
- Используйте try-with-resources для управления ресурсами.
- В библиотеке — документируйте исключения в API и избегайте скрытого поведения.
Рефакторинг — примеры
Исходно (опасно):
try {
risky();
} catch (Exception e) {
// ничего не делаем
}
1) Для библиотечного кода — проброс / обёртка с контекстом
- если метод библиотечный и ошибка должна дойти до пользователя API:
public void doWork() throws SpecificException {
risky();
}
- если нужно дать контекст:
public void doWork() {
try {
risky();
} catch (IOException e) {
throw new MyLibraryException("doWork: failed to read resource", e);
}
}
Пояснение: используйте семантически понятный тип исключения, сохраняйте cause.
2) Для библиотечного кода — возвращаемый Result (альтернатива исключениям)
public Result doWork() {
try {
risky();
return Result.ok(null);
} catch (IOException e) {
return Result.err(new MyError("read failed", e));
}
}
Пояснение: полезно в API, где нужно избежать исключений и давать явно проверяемый результат.
3) Для пользовательского (application) кода — обработка + логирование + UI/фолбек
try {
risky();
} catch (SpecificException e) {
logger.error("Saving user profile failed for id={} : {}", id, e);
showUserError("Не удалось сохранить профиль. Попробуйте ещё раз.");
// опционально: retry / rollback / fallback
}
Особый кейс — InterruptedException
try {
blockingOp();
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // восстановить флаг
throw new RuntimeException("thread was interrupted", e); // или пробросить дальше
}
Агрегирование ошибок (пример для параллельных задач)
List errors = new ArrayList();
for (...) {
try { task(); }
catch (Exception e) { errors.add(e); }
}
if (!errors.isEmpty()) {
throw new AggregateException("Multiple failures", errors);
}
Краткие рекомендации по выбору
- Библиотека: предпочитайте бросать/оборачивать и документировать; не молчите.
- Приложение/UI: перехватите, залогируйте, дайте понятную обратную связь пользователю и/или выполните корректный откат/фолбек.
- Везде: не подавляйте InterruptedException, используйте ясные сообщения и сохраняйте cause.
Если нужно, могу привести конкретный рефакторинг вашего реального метода (покажите код) — предложу вариант для библиотеки и для клиентского кода.