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

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

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

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

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

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

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

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

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

Например:

class Demo {
    static void inner() {
        try {
            throw new IllegalStateException("fail");
        } finally {
            System.out.println("inner");
        }
    }

    static void outer() {
        try {
            inner();
        } finally {
            System.out.println("outer");
        }
    }
}

При вызове outer() сначала будет напечатано inner, затем outer, после чего исключение продолжит раскрутку стека, если его нигде не перехватили. Такой порядок соответствует принципу LIFO: последний начавшийся контекст очистки завершается первым.

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

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

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

Метод открывает внутреннюю транзакцию, затем вызывает компонент, который временно меняет контекст безопасности. Оба действия требуют восстановления состояния при любом исходе.

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

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

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

Дополнительный вопрос: выполняется ли finally, если исключение не удалось обработать ни в одном catch?

Ответ: да, если поток продолжает обычное выполнение Java-кода и управление проходит через соответствующий try. finally выполняется во время раскрутки стека даже при отсутствии подходящего обработчика. Исключения составляют аварийные способы завершения процесса, например принудительное завершение JVM, а также ситуации, когда выполнение физически невозможно продолжить.
Дополнительный вопрос: что произойдёт, если внешний finally выбросит исключение после внутреннего finally, который завершился нормально?

Ответ: исключение из внешнего finally станет текущим исключением и продолжит раскрутку стека. Исходное исключение из внутреннего вызова не будет автоматически помещено в suppressed; без явного связывания оно может исчезнуть из основной диагностики.
Дополнительный вопрос: почему порядок finally важен при вложенном управлении ресурсами?

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