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

Метод выхода контекстного менеджера должен вернуть истинное значение — обычно True, — чтобы исключение, возникшее внутри блока with, было подавлено. Если он возвращает False или None, исключение продолжает распространяться после выхода из блока.

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

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

До этого ту же задачу обычно решали через try...finally. Контекстные менеджеры сделали освобождение ресурсов единообразным и позволили централизованно решить, что делать с исключением при завершении блока.

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

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

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

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

Для объектного контекстного менеджера Python вызывает метод выхода с тремя аргументами: типом исключения, самим исключением и объектом traceback. Если тело with завершилось без ошибки, все три аргумента равны None.

Если исключение возникло, возвращаемое значение проверяется по истинности:

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

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

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

Минимальный пример:

class Transaction:
    def __enter__(self):
        print('начало')
        return self

    def __exit__(self, exc_type, exc, traceback):
        print('откат' if exc_type else 'фиксация')
        return False

try:
    with Transaction():
        raise ValueError('сбой')
except ValueError:
    print('ошибка передана вызывающему коду')

Здесь __exit__ выполняет откат, но возвращает False, поэтому ValueError выходит за пределы with. Если заменить возврат на True, исключение будет подавлено, и обработчик except снаружи не сработает.

Подавление оправдано только при явно определенном контракте, например когда контекстный менеджер намеренно игнорирует конкретное ожидаемое исключение. Для общего обработчика безопасная стратегия — выполнить очистку и вернуть False.

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

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

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

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

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

Подавляет ли __exit__ исключение, возникшее в __enter__?

Нет. Если __enter__ завершился исключением, контекстный менеджер не считается вошедшим в блок, поэтому его __exit__ не вызывается. Для частично выполненной подготовки отдельные действия очистки должны быть организованы внутри самого __enter__ или во вспомогательной логике, которая умеет откатывать незавершенную инициализацию.
Обязательно ли возвращать именно True, чтобы подавить исключение?

Нет. Python проверяет возвращаемое значение по истинности, поэтому технически подойдут и другие истинные объекты. Однако в прикладном коде обычно возвращают именно True для подавления и False для явного сохранения исключения, чтобы намерение было очевидно.
Как подавлять только ожидаемую ошибку, не скрывая остальные?

Нужно проверить тип исключения и вернуть истинное значение только для заранее разрешенного случая. Для всех остальных типов следует вернуть False или не допустить исключение из __exit__; иначе контекстный менеджер станет слишком широким обработчиком и будет маскировать дефекты. При проверке важно учитывать иерархию исключений: проверка через issubclass или isinstance может охватить производные типы, поэтому класс исключения выбирают осознанно.