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

Если finally выполняет return, он подавляет и обычный результат, и исключение, возникшее в try или catch. Вызывающий код получит возвращённое значение, а исходное исключение будет потеряно.

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

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

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

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

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

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

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

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

Поэтому исключение из try в таком случае теряется:

static int readValue() {
    try {
        throw new IllegalStateException("ошибка");
    } finally {
        return 42;
    }
}

public static void main(String[] args) {
    System.out.println(readValue()); // 42
}

Вызов напечатает 42; IllegalStateException не будет выброшено. Аналогично return в finally заменяет значение, возвращаемое из try или catch.

Надёжная практика — не использовать return в finally. Этот блок следует ограничивать освобождением ресурсов и другими действиями, которые не меняют управление потоком. Для управления ресурсами предпочтительнее try-with-resources, поскольку он автоматически закрывает ресурсы и корректно связывает исключения закрытия с основным исключением.

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

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

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

Минусом стало то, что ошибки повреждённого файла и недоступного хранилища маскировались как корректная конфигурация по умолчанию. Система запускалась с неверными параметрами, а причина сбоя становилась недоступной.

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

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

1. Что произойдёт, если try возвращает значение, а finally изменяет локальную переменную?

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

Например, возврат примитивного значения сохраняет вычисленное число, а возврат ссылки сохраняет ссылку на объект; изменение состояния самого объекта в finally может быть заметно вызывающему коду. Это отличается от замены возвращаемого значения новым return.

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

Исключение из finally также заменит результат или исключение, подготовленное в try либо catch. Исходное исключение не станет автоматически подавленным, в отличие от поведения try-with-resources, где исключения закрытия могут попасть в список suppressed у основного исключения.

Поэтому опасно выполнять в finally операции, способные неконтролируемо выбросить исключение. Если такая операция обязательна, её ошибку нужно обрабатывать или явно проектировать правила приоритета исключений.

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

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

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