Коротко о проблеме и как её исправлять.
Проблемы при повторном `throw` без добавления контекста
- Потеря информации: если в `catch` создают и бросают новый экземпляр исключения без передачи исходного в качестве причины, теряется стек вызовов оригинальной ошибки — затрудняет поиск места возникновения проблемы.
- Некорректная трассировка: в логах и APM виден только новый стек, который обычно указывает на место повторного бросания, а не на корень проблемы.
- Потеря семантики: оригинальный тип и сообщение исключения могут быть утрачены, что мешает обработке на вышестоящих уровнях.
- Дублирование логов: логирование в `catch` и повторный выброс без явного указания политики приводит к многократным одинаковым записям.
- Утечка контекста или наоборот — отсутствие контекста: либо добавляется лишняя (и возможно чувствительная) информация, либо никакой полезной дополнительной информации нет.
Как правильно улучшить обработку ошибок (рекомендации)
- Сохраняйте причину (chaining): при создании нового исключения всегда передавайте исходное как cause: `throw new RuntimeException("Контекст: ...", e);`. Это сохраняет исходный стек.
- Не создавайте новый экземпляр с тем же сообщением без `cause` — это уничтожает трассировку.
- Используйте специализированные/пользовательские исключения для добавления семантики и контекста (например, `UserServiceException extends RuntimeException`), либо добавляйте в сообщение понятный контекст (идентификаторы, состояние), аккуратно редактируя конфиденциальные данные.
- Логирование: логируйте либо в месте обработки (где проблема окончательно решается), либо логируйте и добавляйте контекст, но избегайте логирования на каждом слое (чтобы не засорять трассировки).
- Не ловите `Exception`/`Throwable` широко без необходимости — ловите конкретные исключения.
- Используйте `try-with-resources` и `addSuppressed` (Java 7+) — чтобы не терять исключения из finally/ресурсов.
- Для распределённых систем: добавляйте correlation id / request id (например, через MDC), чтобы связать события в логах и трассировках.
- Для часто повторяющегося обёртывания создайте утилиту/фабрику исключений, формирующую понятный message и устанавливающую cause.
Плохой пример (теряется стек):
catch (SQLException e) {
throw new RuntimeException("DB error"); // исходный e теряется
}
Хороший пример (сохранён cause и контекст):
catch (SQLException e) {
throw new DataAccessException("Failed to load orders for userId=" + userId, e);
}
Дополнительно
- Если вам нужно просто перекинуть исключение дальше без модификации, используйте `throw e;` (он сохранит стек). Будьте внимательны: если вы присвоите `e = ...` — стек может потеряться.
- Если добавляете информацию, делайте это в новом исключении с `cause`, а не переписывайте исходное сообщение.
- При логировании исключения используйте формат логера, передавая исключение как параметр (например, `logger.error("msg {}", context, e)`), чтобы лог-фреймворк напечатал весь стек.
Итог: никогда не бросайте новый exception без передачи исходного `cause` и по возможности добавляйте полезный (и безопасный) контекст либо используйте специализированные исключения и централизованную стратегию логирования/корреляции.