Краткий ответ

return из блока finally отменяет ранее подготовленный результат из try и становится фактическим результатом метода. Если finally завершает выполнение через return, он также подавляет исключение, которое могло возникнуть в try или быть выброшено из него.

Такой код компилируется, но обычно считается плохой практикой: он скрывает исходный результат или ошибку и усложняет диагностику.

Исторический контекст

Конструкция try–finally предназначена для гарантированного выполнения завершающих действий: освобождения ресурсов, восстановления состояния или снятия служебных блокировок. Блок finally выполняется при обычном выходе из try, при return, а также при передаче исключения дальше, если выполнение процесса не прервано внешними обстоятельствами.

Изначально это отделяло основную логику операции от обязательной очистки. Позднее для типичного управления ресурсами в Java появился try-with-resources, который безопаснее обрабатывает исключения при закрытии ресурсов.

Постановка проблемы

Разработчик может считать, что return в try окончательно определяет результат метода. Однако перед фактическим выходом Java сначала выполняет finally, поэтому его завершение способно изменить поведение метода.

Особенно опасна ситуация, когда finally содержит return или выбрасывает новое исключение. В этом случае исходный результат или исключение теряются, что приводит к неверным данным, скрытым ошибкам и трудной отладке.

Подробное решение

При выполнении return в try выражение результата сначала вычисляется и сохраняется. Затем запускается finally.

Если finally завершается нормально, сохранённый результат используется для выхода из метода. Если же finally выполняет собственный return, он заменяет ранее подготовленный результат. Аналогично, throw из finally заменяет первоначальный результат или исключение.

Минимальный пример:

public static int value() {
    try {
        return 1;
    } finally {
        return 2;
    }
}

Метод вернёт 2. Значение 1 уже вычислено, но собственный return из finally завершает метод другим результатом.

Если finally только изменяет переменную, это не обязательно изменит уже вычисленный результат примитивного типа: результат return был сохранён до выполнения finally. Для ссылочного результата сохраняется сама ссылка, а не неизменяемая копия объекта, поэтому изменение состояния объекта в finally может быть видимо вызывающему коду.

Практическое правило: в finally не следует использовать return, throw без крайней необходимости или код, способный неожиданно завершить выполнение. Для закрытия ресурсов предпочтителен try-with-resources, поскольку он сохраняет исходное исключение и добавляет исключение закрытия как подавленное, когда это необходимо.

Ситуация из практики

В сервисном методе чтения файла разработчик поместил return результата в try, а в finally добавил return значения по умолчанию. При ошибке чтения исключение также подавлялось, и вызывающий код получал значение по умолчанию вместо сигнала об ошибке.

Рассматривались два варианта. Сохранить return в finally было проще, но это скрывало ошибки. Удалить return из finally и оставить там только закрытие ресурса было безопаснее, однако ручное закрытие требовало аккуратно обрабатывать исключения. Выбран try-with-resources: он автоматически закрывает ресурс, не меняет успешный результат метода и сохраняет информацию об ошибке.

В результате вызывающий код различает успешное чтение и сбой, а исключения закрытия не маскируют первоначальную причину проблемы.

Что кандидаты часто упускают

Всегда ли finally выполняется перед выходом из метода?

Почти всегда при обычном выполнении Java-программы: при return, throw и нормальном завершении try или catch. Но гарантии нет, если JVM завершена принудительно, например из-за внешнего завершения процесса или аварийного прекращения работы виртуальной машины. Поэтому finally нельзя считать механизмом абсолютной гарантии сохранения данных.

Что произойдёт, если в try выброшено исключение, а finally завершает метод через return?

Исключение будет подавлено, и метод вернёт значение из finally. Вызывающий код не узнает о первоначальной ошибке, если она не была сохранена отдельно. Именно поэтому return в finally опасен: он способен превратить отказ операции в внешне успешный результат.

Чем отличается изменение объекта в finally от замены возвращаемой ссылки?

Ссылка, подготовленная для return, сохраняется до выполнения finally. Если finally изменит объект, на который она указывает, вызывающий код получит ту же ссылку, но уже с изменённым состоянием. Если же finally присвоит локальной переменной другую ссылку, это не изменит ранее сохранённую ссылку и само по себе не повлияет на результат метода.