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

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

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

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

Декоратор contextmanager из модуля contextlib упрощает создание таких объектов. Разработчик описывает сценарий подготовки, использования ресурса и завершения в одной генераторной функции, вместо явной реализации методов __enter__ и __exit__.

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

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

Особенно важно понимать, что yield не просто возвращает значение. Он разделяет вход в контекст и выход из него: всё до yield выполняется при входе, а всё после него — при выходе, причём исключение может быть доставлено прямо в эту точку.

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

При вызове генераторной функции с @contextmanager сразу не выполняется её тело: создаётся объект контекстного менеджера. При входе в with он запускает генератор до первого yield; значение, переданное yield, становится результатом __enter__ и может быть присвоено через as.

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

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

Блок finally после yield выполняется при любом выходе после успешного входа, поэтому именно там обычно размещают безусловное освобождение ресурса. Если ошибка произошла до yield, вход в контекст не завершился, и обычный выход через __exit__ не происходит.

from contextlib import contextmanager

@contextmanager
def transaction():
    print("begin")
    try:
        yield
    except Exception:
        print("rollback")
        raise
    else:
        print("commit")
    finally:
        print("close")

with transaction():
    raise ValueError("bad data")

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

Главный компромисс состоит в удобстве против явности. contextmanager сокращает шаблонный код, но скрывает протокол __enter__ и __exit__; для сложного состояния, повторного использования или нетривиальной типизации отдельный класс-контекстный менеджер может быть понятнее.

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

Сервис записывает изменения в базу данных и должен либо зафиксировать всю операцию, либо отменить её. Рассматривались три варианта: ручные вызовы commit и rollback, класс с __enter__ и __exit__, а также генераторный контекстный менеджер.

Ручной вариант проще начать, но легко пропустить откат в новом обработчике ошибки. Класс лучше подходит для сложного жизненного цикла и повторного использования, однако требует больше шаблонного кода. Генераторный вариант компактно выражает последовательность «начать — выполнить тело — зафиксировать или откатить — закрыть».

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

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

Что произойдёт, если обработчик исключения после yield не выполнит повторный raise?

Если генератор поймает исключение и завершится без нового исключения, реализация contextmanager сочтёт его обработанным. Метод выхода вернёт признак подавления, поэтому исключение не выйдет за пределы with. Это допустимо только для намеренно поглощаемых ошибок; для транзакций обычно нужен повторный raise.
Всегда ли выполняется код после yield?

Нет. Он выполняется только если генератор успешно дошёл до yield. Исключение во время подготовки до yield означает, что вход в контекст не состоялся. Для безусловной очистки после успешного входа используют finally, но ошибки самой подготовки нужно обрабатывать отдельно.
Можно ли безопасно использовать один экземпляр генераторного контекстного менеджера несколько раз?

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