Контекстные менеджеры и исключения

Именно поэтому: он ловит и то, что ловить нельзя.

Голый except: эквивалентен except BaseException:, а от BaseException наследуются три вещи, которые обязаны проходить насквозь: KeyboardInterrupt, SystemExit и GeneratorExit.

while True:
    try:
        do_work()
    except:              # съедает Ctrl-C
        continue

Этот цикл невозможно остановить с клавиатуры: каждое нажатие ловится и игнорируется. То же с sys.exit() внутри блока — процесс не завершится. А проглоченный GeneratorExit ломает закрытие генераторов и даёт RuntimeError: generator ignored GeneratorExit.

Правильная граница — except Exception: он ловит всё прикладное и пропускает управляющие сигналы. И даже он уместен только на верхнем уровне — в обработчике запроса, в главном цикле воркера, — где задача «залогировать и продолжить с следующим элементом».

for item in queue:
    try:
        handle(item)
    except Exception:                  # не BaseException
        log.exception("упало на %s", item)   # с трассировкой, а не str(e)

И отдельно: log.exception вместо log.error(str(e)). Строка исключения без трассировки — самая частая причина, по которой инцидент невозможно разобрать: видно что, не видно где.

Затем, что автоматический контекст говорит «случилось во время», а from говорит «случилось из-за». Это разные утверждения.

Python хранит две разные ссылки. __context__ проставляется сам, когда одно исключение возникло внутри обработки другого. __cause__ проставляется только явным from и означает причинно-следственную связь.

try:
    try: 1 / 0
    except ZeroDivisionError as e:
        raise ValueError("плохие данные")
except ValueError as e:
    print(e.__context__, "|", e.__cause__)
# → division by zero | None

В трассировке разница видна словами: без from печатается «During handling of the above exception, another exception occurred», с from — «The above exception was the direct cause».

И третья форма, про которую забывают: raise ... from None — она подавляет цепочку целиком. Нужна там, где внутреннее исключение — деталь реализации, которую незачем показывать пользователю библиотеки:

def get_config(d, key):
    try:
        return d[key]
    except KeyError:
        raise ConfigError(f"нет ключа {key}") from None   # KeyError не всплывёт

Правило: from e — когда переупаковываешь чужую ошибку в свою и хочешь сохранить след. from None — когда чужая ошибка была способом узнать факт, а не самой проблемой. Ничего — когда исключение возникло случайно и цепочка честно это отражает.

Не баг, а прямое следствие того, что finally обязан выполниться при любом выходе из блока.

Если в finally есть return, break или continue, они задают новый способ выхода из функции — и он замещает тот, который был в процессе. Летящее исключение просто перестаёт лететь.

def f():
    try:
        raise ValueError("важная ошибка")
    finally:
        return "всё хорошо"

print(f())      # → всё хорошо      исключение исчезло бесследно

Ни трассировки, ни записи в лог, ни следа в __context__. С точки зрения вызывающего функция отработала успешно.

Как это выглядит в реальном коде. Не так явно: обычно это finally, в котором делают уборку и на всякий случай возвращают статус, или цикл, где в finally стоит continue ради «пропустим битую запись». Второй вариант особенно коварен — он глотает и KeyboardInterrupt.

В 3.14 на такую конструкцию добавили предупреждение компилятора (SyntaxWarning), но поведение оставили — R9: менять семантику нельзя, на неё мог опереться существующий код. Так что диагностика есть, а защиты нет.

Правило: в finally только уборка. Всё, что меняет поток управления, — в else или после блока.

Есть, и существенная: __exit__ видит исключение и может его подавить, а finally — нет.

finally выполняется «вслепую»: он не знает, вышли из блока нормально или с ошибкой, и какой именно. __exit__ получает три аргумента — тип, значение, трассировку — и его возвращаемое значение решает судьбу исключения.

class Suppress:
    def __enter__(self): return self
    def __exit__(self, exc_type, exc, tb):
        print("поймал:", exc_type)
        return exc_type is ValueError     # True → исключение подавлено

with Suppress():
    raise ValueError("тихо")
print("дошли сюда")
# → поймал: <class 'ValueError'>
# → дошли сюда

На этом стоит contextlib.suppress, на этом же — транзакции, которые откатываются при ошибке и коммитятся при успехе, различая случаи.

Второе отличие — переиспользование. try/finally надо повторять в каждом месте; менеджер пишется один раз и получает имя. Плюс contextlib.contextmanager позволяет описать его генератором, где yield и есть граница блока.

Где try/finally всё-таки уместен: одноразовая уборка, ради которой заводить класс избыточно, и случаи, где вход и выход не парные — например ресурс захвачен выше по стеку.

Важное общее: полномочие подавлять исключение — то, чего нет у деструктора в C++. Там из деструктора исключение вообще нельзя выпустить, и решение о судьбе ошибки принимается вне RAII. Здесь наоборот.