Исключения и finally: одно слово, после которого функция перестаёт падать

База: четыре части, и у каждой своя роль

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

• try — попытка: код, который может не получиться;
• except — обработка: что делать, если не получилось, и с какой именно ошибкой;
• else — ветка «ошибки не было»: код, который имеет смысл только тогда, когда попытка удалась;
• finally — выход в любом случае: код, который выполняется и после удачи, и после ошибки.

Одним примером все четыре видно сразу:

try:
    value = int(raw)              # попытка
except ValueError:
    value = 0                     # сюда попадём, только если попытка не удалась
else:
    audit(value)                  # а сюда — только если удалась
finally:
    counter += 1                  # а это выполнится в любом из двух случаев

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

И здесь же главный вопрос урока. finally выполняется, пока исключение летит наружу, — а что будет с самим исключением, если finally при этом сам решит выйти наружу: сделает return, break или continue?

Обычно ничего необычного: finally отработал, исключение полетело дальше. Но в этом одном случае — исключение исчезает. Не откладывается, не заменяется: его больше нет, и функция возвращает значение так, будто ошибки не было.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования: try — попытка, except — обработка, else — ветка удачи, finally — выход в любом случае, и выход этот умеет проглотить ошибку. Всё дальнейшее — про то, как это выглядит в коде, который никто не заподозрит; про то, чем голый except: отличается от except Exception:; про цепочки исключений и про группы, в которых ошибок сразу несколько.

Механизм 1: одно слово, после которого функция перестаёт падать

Справочник формулирует это одним предложением: If the finally clause executes a return, break or continue statement, the saved exception is discarded (Если предложение finally выполняет return, break или continue, сохранённое исключение отбрасывается).

Слово «discarded» здесь надо читать буквально. Не «перекрывается», не «заменяется» — исчезает:

def never_fails():
    try:
        raise RuntimeError("что угодно")
    finally:
        return None

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

То же делает break, и заметить его труднее, потому что слова return рядом нет:

for _ in range(1):
    try:
        raise KeyError("и этого")
    finally:
        break

Четвёртый случай на рисунке — тот же return в finally, но без исключения: отбрасывается уже обычный результат.

Механизм 2: ошибка, которая не падает

Те же строки, что в уроке про контекстные менеджеры. Механизм другой — неверный ответ тот же.

ROWS = [
    {"id": 1, "amount": "100"},
    {"id": 2, "amount": "нет данных"},   # битая
    {"id": 3, "amount": "50"},
    {"id": 4, "amount": "25"},
]

Правильный вариант: finally только закрывает ресурс, а что делать с битой строкой, решает отдельный except.

def correct(rows):
    total = 0
    for row in rows:
        handle = open("/dev/null", "w")
        try:
            total += int(row["amount"])
        except ValueError:
            continue
        finally:
            handle.close()
    return total

Неправильный выглядит аккуратнее — «закрыли ресурс и честно вернули то, что успели посчитать»:

def broken(rows):
    total = 0
    for row in rows:
        handle = open("/dev/null", "w")
        try:
            total += int(row["amount"])
        finally:
            handle.close()
            return total          # ← вот здесь

Проверено запуском (одинаково на 3.13.7 и 3.14.7):

Потеряно 75 из 175, ни одного исключения в логе. Разница между двумя функциями — одна строка, и та выглядит как забота о ресурсе. Но return в finally выходит из функции на первой же битой строке, отбросив исключение по дороге, — а except ValueError: continue в правильном варианте просто идёт к следующей записи.

Механизм 3: else — зачем он, если можно просто дописать в try

Разница видна не в успешном случае, а в том, что происходит с исключением из дописанного кода.

Справочник: The optional else clause is executed if the control flow leaves the try suite, no exception was raised… Exceptions in the else clause are not handled by the preceding except clauses (Необязательное предложение else выполняется, если управление вышло из блока try и исключение не возникло… Исключения в предложении else не обрабатываются предшествующими предложениями except).

То есть else — это способ сузить try до строки, которая действительно может упасть:

try:
    value = registry[key]          # может бросить KeyError
except KeyError:
    value = default
else:
    audit(value)                   # KeyError отсюда НЕ будет перехвачен

Если audit внутри себя бросит KeyError, обработчик его не поймает — и правильно: этот except написан для одной конкретной строки, а не для всего, что случайно окажется рядом. Проверено запуском: исключение, брошенное в else, уходит наружу мимо стоящего выше except.

Если к тому же блоку дописать finally, порядок получается такой (проверено запуском):

без исключения:  try -> else -> finally
с исключением:   try -> except -> finally

Механизм 4: голый except: ловит больше, чем вы думаете

KeyboardInterrupt и SystemExit — не Exception. Проверяется одной строкой: issubclass(SystemExit, Exception) даёт False, а MRO KeyboardInterrupt — это KeyboardInterrupt → BaseException → object.

Документация объясняет, почему так сделано: The exception inherits from BaseException so as to not be accidentally caught by code that catches Exception and thus prevent the interpreter from exiting (Исключение наследуется от BaseException, чтобы его случайно не поймал код, ловящий Exception, и тем самым не помешал интерпретатору завершиться).

То есть иерархия построена специально, чтобы except Exception: пропускал Ctrl+C. А голый except: эту защиту снимает: он ловит BaseException, и программа перестаёт закрываться по Ctrl+C.

Механизм 5: цепочки — __context__, __cause__ и from None

Исключение, возникшее внутри except, само получает ссылку на предыдущее — это PEP 3134, и делается это интерпретатором без участия автора кода.

Третья строка — самая полезная. from None не удаляет предыдущее исключение: __context__ остаётся на месте, меняется только __suppress_context__ — флаг, по которому трассировка предыдущее исключение не печатает.

Практически это значит, что from None — про читаемость сообщения, а не про сокрытие данных. Предыдущее исключение по-прежнему достижимо из объекта, и в обработчике верхнего уровня его можно записать в лог.

Ещё одна деталь, и уже не из PEP 3134, а из справочника языка: имя из except … as e удаляется в конце блока. Справочник даёт точную расшифровку — это как если бы тело было обёрнуто в try: … finally: del N. Обращение к e после блока даёт NameError; чтобы сохранить объект, его надо присвоить другому имени.

Механизм 6: группы — чем except* отличается от except

PEP 654 (3.11) добавил тип ExceptionGroup и синтаксис except* для одной задачи: бросить и обработать несколько независимых ошибок сразу. Типичный источник — параллельные задачи, где каждая упала по-своему. Именно это и отдаёт asyncio.TaskGroup, и цепочка тут прямая:

1. TaskGroup отменяет соседей и собирает их ошибки;
2. отдаёт он их одним объектом — ExceptionGroup, внутри которого несколько независимых исключений;
3. except* разбирает группу по типам, и каждая ветка выполняется не более одного раза.

Разбор TaskGroup — в уроке про async/await; здесь разбирается вторая половина цепочки. Всё ниже проверено запуском.

Группа — это отдельный объект, а не её содержимое. ExceptionGroup не «раскрывается» в свои ошибки: обычный except ValueError: не поймает группу, даже если внутри ровно один ValueError.

try:
    raise ExceptionGroup("одна", [ValueError("одинокая")])
except ValueError:
    print("сюда не попадём")
except ExceptionGroup as e:
    print("поймали группу:", type(e).__name__)   # → поймали группу: ExceptionGroup

Обычный except Exception группу поймает, но целиком — одним объектом, а не по одной ошибке.

except* разбирает группу по типам и может сработать несколько раз за один raise. Каждая ветка получает подгруппу — снова ExceptionGroup — со всеми листьями своего типа. PEP: a single exception group can cause several except* clauses to execute, but each such clause executes at most once (одна группа исключений может привести к выполнению нескольких предложений except*, но каждое из них выполняется не более одного раза).

try:
    raise ExceptionGroup("две беды", [ValueError("значение"), KeyError("ключ")])
except* ValueError as eg:
    print("ValueError:", [str(x) for x in eg.exceptions])   # → ValueError: ['значение']
except* KeyError as eg:
    print("KeyError:", [str(x) for x in eg.exceptions])      # → KeyError: ["'ключ'"]
# за один raise сработали ОБЕ ветки

Важное: переменная ветки (eg) — не одно исключение, а группа; сами ошибки лежат в eg.exceptions.

Необработанный остаток летит дальше — снова группой. Если ветки разобрали не всё, оставшиеся листья продолжают распространяться как ExceptionGroup, а не как отдельные исключения:

try:
    raise ExceptionGroup("три", [ValueError(), KeyError(), TypeError()])
except* ValueError:
    pass
# наружу летит ExceptionGroup([KeyError(), TypeError()])

Смешивать except и except* в одном try нельзя — это синтаксическая ошибка. Ветки одного try либо все обычные, либо все со звёздочкой.

Глубже: сколько стоит try

Теперь то, о чём спорят без чисел: во что обходится сама конструкция.

Колонки читаются по отдельности. Сборки 3.13.7 и 3.14.7 различаются не только компилятором, и разрыв между колонками — не разница между версиями языка.

Разницу между первыми двумя строками надо сперва сопоставить с разбросом самого прибора — и прогон это делает сам, повторяя весь замер пять раз:

  РАЗМАХ ПО 5 ПОВТОРАМ ВСЕГО ЗАМЕРА
  без try                        38.7 ..   39.1 нс  размах   0.4
  try/except, не сработал        40.5 ..   40.9 нс  размах   0.4
  try/except, сработал          201.1 ..  203.4 нс  размах   2.3

  разница между первыми двумя строками     1.8 нс
  наибольший размах этих же двух строк      0.4 нс
  различима ли разница прибором          да

Различима: 1,8 нс против размаха 0,4. Значит, утверждение здесь не «неотличимо», а более узкое и более полезное: try, который не сработал, стоит около двух наносекунд — пять процентов, — и знак этой разницы устойчив, во всех пяти повторах вариант с try чуть медленнее.

Вопрос из-за этого меняется. Он уже не «есть ли разница» — есть, — а «стоит ли она того», и это вопрос к величине. Пять процентов на пустом вызове не окупают ни одной перестройки кода: чтобы они дали заметный выигрыш, try должен стоять в цикле, который сам по себе и есть узкое место.

Почему так, видно в байт-коде. SETUP_FINALLY описана в документации dis среди псевдоинструкций, и про них сказано прямо: They do not appear in Python bytecode. They are used by the compiler but are replaced by real opcodes or removed before bytecode is generated (Их нет в байт-коде Python. Компилятор ими пользуется, но до создания байт-кода заменяет их настоящими инструкциями или убирает). Проверено дизассемблером на всех четырёх версиях — SETUP_FINALLY нет ни в одной.

Вот что реально исполняется:

без try:  RESUME     LOAD_NAME  PUSH_NULL  CALL  POP_TOP
в try:    RESUME NOP LOAD_NAME  PUSH_NULL  CALL  POP_TOP

Разница — один NOP. Куда делась обработка? В отдельную таблицу: дизассемблер печатает её блоком ExceptionTable под кодом. Пока исключения нет, таблицу никто не читает.

И здесь важно назвать границу наблюдения, а не только число. Замерялся один пустой вызов в цикле, на двух сборках CPython, на одной машине. Отсюда следует ровно одно: в этом замере на успешном пути try стоит около двух наносекунд — а не «try бесплатен» вообще и не «try можно ставить куда угодно без последствий». Вложенные обработчики, finally с работой внутри, try внутри генератора замером не покрыты.

Поэтому практический вывод пишется от границы, а не от числа: аргумент «уберём try, он тормозит» ничем не подкреплён — если он звучит, просят замер, а не убирают конструкцию. Дорого стоит сработавшее исключение — впятеро. Вот его в горячем цикле как штатный способ ветвления использовать и не стоит.

Глубже: что изменилось в 3.14

Компилятор начал предупреждать о return и break, выходящих из finally. Проверено компиляцией:

3.11.15   предупреждений: 0
3.12.3    предупреждений: 0
3.13.7    предупреждений: 0
3.14.7    SyntaxWarning: 'return' in a 'finally' block

Для break — своё сообщение, 'break' in a 'finally' block.

Поведение при этом не изменилось. PEP 765 (Ирит Катриэль, Алисса Кофлан) говорит об этом прямо: we leave it open whether, and when, this will become a SyntaxError (мы оставляем открытым вопрос, станет ли это когда-нибудь SyntaxError и когда именно). Код, написанный так, работает ровно как раньше — просто теперь об этом сообщают. Причина осторожности названа в самом PEP: прогоны с -We превращают предупреждения в ошибки, и немедленный запрет сломал бы их.

Глубже: история версий

Как отвечать на собеседовании

Короткий ответ: try — попытка, except — обработка ошибки, else — ветка «ошибки не было», finally — выход в любом случае. И главное про finally: если он сам передаёт управление наружу — return, break, continue, — летящее исключение исчезает. Справочник формулирует это одним предложением: «сохранённое исключение отбрасывается».

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Первое — показать, как это выглядит в настоящем коде: return в finally выглядит как забота о ресурсе, а на деле выходит из функции на первой же ошибке; те же строки, что в уроке про контекстные менеджеры, дают 100 вместо 175 без единого исключения в логе. С 3.14 компилятор об этом предупреждает (PEP 765), но только предупреждает: поведение осталось прежним.

Второе — голый except: ловит BaseException, то есть Ctrl+C и sys.exit(); иерархия сделана именно так, чтобы except Exception: их пропускал.

Третье — если разговор ушёл в скорость, назвать замер вместе с его границей: на успешном пути дополнительная стоимость try в этом замере — около двух наносекунд (40,5 нс против 38,7 у того же кода без try — пять процентов, и это больше размаха прибора, 0,4 нс), а сработавшее исключение стоит 201,1 нс — впятеро дороже. Причина структурная: SETUP_FINALLY — псевдоинструкция, в байт-код она не попадает, и на счастливом пути try добавляет один NOP. Вывод отсюда узкий: убирать try ради скорости незачем, а использовать исключение как штатное ветвление в горячем цикле — есть за что.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

def swallow():
  try:
      raise ValueError("boom")
  finally:
      return "ok"


def keep():
  try:
      raise ValueError("boom")
  finally:
      pass


print(swallow())
try:
  keep()
except ValueError as e:
  print("ValueError:", e)

ok
ValueError: boom

ValueError: boom
ValueError: boom

ok
ok

Traceback (most recent call last):
ValueError: boom

Проверка знаний