Кейс: finally проглотил исходное исключение

В код-ревью встретился метод, закрывающий ресурс вручную в finally после try с бизнес-логикой. Исключение из try терялось без единой строки в логе — а стектрейс в проде вёл совсем не туда, где была реальная причина.

Механика проста: если try бросает исключение, а finally тоже бросает исключение (или делает return), исходное исключение из try подавляется. JVM пробрасывает наверх только то, что вылетело последним из finally.

try { connection.executeUpdate(sql); // бросает SQLException } finally { connection.close(); // тоже бросает SQLException // наружу уйдёт только это исключение }

Правильный фикс — try-with-resources: он использует suppressed exceptions, оба исключения доступны через getSuppressed() на исходном, а не молча теряются. Ручной finally с close() без try-with-resources всегда рискует подавить причину сбоя.

Один throw в finally может стереть настоящую причину падения — и объяснить это на ревью проще, чем найти постфактум в проде.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки