Ответ на вопрос.

История вопроса: До Python 2.5 взаимодействие между операторами return в блоках finally и активными исключениями было неопределённым и зависело от платформы. PEP 341 стандартизировал иерархию исключений и укрепил правило о том, что блоки finally выполняются перед выходом из функции, но детали реализации относительно того, как интерпретатор сохраняет ожидаемые значения возврата или исключения во время выполнения кода очистки, остались внутренней деталью компилятора. Этот механизм гарантирует, что ресурсы освобождаются предсказуемо, не теряя информации о том, должно ли функция вернуть значение, передать исключение или передать управление.

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

Решение: Компилятор выдает блок finally один раз в конце блока try, затем дублирует его (или переходит к нему) на специфических смещениях для обработки исключений и путей возврата. Операция SETUP_FINALLY помещает блок в стек блоков фрейма, который указывает на версию обработчика исключений кода finally. Когда происходит исключение, интерпретатор использует эту запись в стеке, чтобы перейти к обработчику. Для нормальных возвратов POP_BLOCK удаляет обработчик, но если return происходит внутри try, интерпретатор сохраняет значение возврата, выполняет блок finally, и если этот блок завершается без нового return, восстанавливает исходное значение возврата. Если блок finally содержит собственный return, он просто выполняет RETURN_VALUE, который перезаписывает ожидаемое значение возврата или подавляет активное исключение, очищая состояние исключения и возвращая новое значение.

import dis

def example():
    try:
        return "try_value"
    finally:
        return "finally_value"

# Байткод показывает, что логика finally дублируется
# на смещениях для обработки исключений и нормального возврата
dis.dis(example)

Ситуация из жизни

Описание проблемы: В системе обработки финансовых транзакций функция process_withdrawal() захватывает блокировку потока для обеспечения атомарных обновлений баланса. Блок try вычисляет новый баланс и подготавливает запись транзакции для возврата. Однако проверка соответствия в блоке finally обнаруживает подозрительный флаг на счете. Требование заключается в том, чтобы всегда освобождать блокировку (очистка), но если флаг установлен, вернуть уведомление об отказе вместо записи транзакции, эффективно подавляя успешное вычисление.

Рассмотренные различные решения:

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

Другим рассмотренным решением было использование менеджера контекста для захвата блокировки и обработки логики соответствия через исключения. Если флаг обнаруживался, вызывать пользовательское исключение ComplianceError из блока finally (или вложенной функции), перехватывать его снаружи и возвращать уведомление об отказе из обработчика исключений. Преимущества включают соблюдение принципа о том, что finally должен использоваться только для очистки, а не для бизнес-логики, и использование механизма исключений Python для управления потоком. Недостатки включают накладные расходы на создание исключений и тот факт, что вызов нового исключения, пока другое может быть активным (если блок try завершился неудачей), затмит исходную ошибку, усложняя отладку.

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

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

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

Почему оператор break или continue внутри блока finally также подавляет активное исключение, и как это отличается от return с точки зрения очистки стека?

Когда блок finally выполняется в результате активного исключения, интерпретатор сохраняет тип исключения, значение и трассировку в состоянии фрейма. Если блок finally выполняет оператор break или continue, CPython явно очищает состояние исключения (используя POP_BLOCK и сбрасывая переменные исключений) перед переходом к целевой точке управления циклом. Это фактически теряет исключение. Разница с return тонкая: return помещает значение в стек и сигнализирует фрейму о выходе, в то время как break/continue переходят к смещению байт-кода. Оба оператора вызывают распаковку стека блоков, которая включает в себя очистку состояния исключения, но return также обрабатывает сохранение стека значений для значения возврата, тогда как break просто отбрасывает любую ожидаемую информацию об исключении, не сохраняя значение для вызывающего кода.

Как присутствие выражения yield внутри блока try-finally изменяет генерацию байт-кода для очистки, особенно в отношении приостановки генератора?

Когда CPython обнаруживает yield внутри блока try с ассоциированным finally, он генерирует коды операций YIELD_VALUE, за которыми следует специальная обработка в END_FINALLY. Проблема в том, что генератор может быть приостановлен в точке yield, и если генератор позже закрывается (через close() или сборку мусора), интерпретатор должен возобновить генератор, чтобы выполнить блок finally. Это обрабатывается логикой GENERATOR_RETURN (или RETURN_GENERATOR в новых версиях) и YIELD_FROM. Компилятор добавляет SETUP_FINALLY, как обычно, но указатель f_lasti (последняя инструкция) фрейма позволяет повторный вход. Если генератор закрывается, Python вызывает исключение GeneratorExit в точке приостановки, что запускает выполнение блока finally перед окончательным завершением генератора. Кандидаты часто упускают, что yield заставляет код finally быть защищённым от повторного входа, и что объект генератора держит ссылку на фрейм, что позволяет выполнять блок finally после приостановки.

Что происходит с контекстом исключения (__context__ и __cause__), когда блок finally порождает новое исключение, обрабатывая существующее?

Если блок finally вызывает новое исключение, пока старое активно (либо из блока try, либо будучи распространённым), новое исключение становится "текущим" исключением, а старое исключение прикрепляется к его атрибуту __context__ через цепочку контекста. Если блок finally использует raise NewException() from None, он явно разрывает цепочку, устанавливая __suppress_context__ на True. Однако если блок finally выполняет return вместо вызова, исключение полностью подавляется (в соответствии с основным ответом), и никакая цепочка не происходит, потому что состояние исключения очищается из фрейма перед выходом из функции. Кандидаты часто путают это с поведением внутри блоков except, где raise без from автоматически создает цепочку, не осознавая, что блоки finally участвуют в этом механизме цепочки аналогично любому другому блоку кода, но с добавленной сложностью в том, что они могут выполняться во время развертывания стека.