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

Метод вернёт 2. При выходе из try Java сначала подготавливает результат return 1, затем выполняет finally; собственный return из finally заменяет ранее подготовленный результат.

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

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

Изначальная проблема — не допустить пропуска очистки из-за нескольких путей выхода. Однако finally не должен менять результат управления, потому что это делает поведение метода неожиданным и может скрыть ошибку.

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

В примере return 2 из finally подавляет return 1. Поэтому вызывающий код получает не основное бизнес-значение, а значение из блока очистки.

Если вместо return 1 возникнет исключение, return из finally также подавит это исключение. В результате первоначальная причина сбоя будет потеряна, а отладка и диагностика станут значительно сложнее.

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

При выполнении return 1 выражение 1 вычисляется, и Java запоминает подготовленный результат. Перед фактическим выходом из метода JVM выполняет finally. Если finally завершается нормально, управление продолжает исходный выход; если он содержит return, throw или другое внезапное завершение, именно оно становится итоговым.

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

// getValue() == 2

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

Безопаснее не возвращать значение из finally. Если требуется изменить состояние, делайте это явно, а очистку ресурсов поручайте try-with-resources, который корректно связывает основное исключение с исключением при закрытии ресурса.

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

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

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

Предпочтительное решение — использовать try-with-resources, а результат обработки возвращать после блока. Тогда обычный результат не перезаписывается кодом очистки, а исключения сохраняют диагностическую информацию. Это уменьшает риск потери ошибок и делает поведение метода очевидным.

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

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

Метод вернёт значение из finally, а исходное исключение будет подавлено. Например, throw new IOException() в try исчезнет для вызывающего кода, если finally содержит return.

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

2. Когда вычисляется выражение исходного return?

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

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

3. Можно ли безопасно выбросить исключение из finally?

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

Для закрытия ресурсов лучше применять try-with-resources: если и основная операция, и закрытие завершились исключениями, исключение закрытия обычно сохраняется как подавленное у основного. Это позволяет не потерять исходную диагностическую информацию.