Как работает exception handling в Python?

Скелет конструкции

try:
    risky()                         # код, который может бросить
except ValueError as exc:           # ловим конкретный тип
    handle_value_error(exc)
except (KeyError, IndexError):      # tuple — несколько типов в одном except
    pass
except Exception:                   # широкая ловушка (с осторожностью)
    log.exception("unexpected")
    raise                           # пробрасываем дальше
else:
    # только если в try не было исключения
    log.info("ok")
finally:
    # всегда — успех, исключение, return, break
    cleanup()

Как Python ищет обработчик

Когда внутри try возникает исключение, Python создаёт объект-исключение и traceback, затем идёт по except-блокам сверху вниз. Первый блок, для которого isinstance(exc, declared_type) возвращает True, выполняется. Если не нашёл — поднимается по стеку вызовов до следующего try.

Пробрасывание и chaining

def parse_int(s: str) -> int:
    try:
        return int(s)
    except ValueError as exc:
        # raise ... from exc — явное связывание причин (atribут __cause__)
        raise ValueError(f"bad integer: {s!r}") from exc

# raise без from — связь через __context__ (показывается как
# "During handling of the above exception, another exception occurred")

# raise без аргументов внутри except — пробросить текущее исключение
def with_log():
    try:
        risky()
    except Exception:
        log.exception("failed")
        raise          # сохраняет original traceback

Для подавления связи (если хотите скрыть исходную причину) используйте raise X from None.

else и finally

def read_safe(path):
    try:
        f = open(path)
    except OSError:
        return None
    else:
        # выполнится только если open() не упал; узкий try — узкий except
        try:
            return f.read()
        finally:
            f.close()         # выполнится всегда, даже при ошибке read()

В finally return или raise перебивает результат try-блока — используйте осторожно.

Группы исключений (3.11+)

async def main():
    async with asyncio.TaskGroup() as tg:
        tg.create_task(a())
        tg.create_task(b())
    # если обе упадут — получите ExceptionGroup

try:
    await main()
except* ValueError as eg:
    for err in eg.exceptions:
        log.error(err)
except* OSError as eg:
    ...

Подводные камни

• except Exception: без re-raise — баги тонут в логе или вообще исчезают.
• except: без типа = except BaseException: — ловит Ctrl+C, см. py-bare-except-056.
• raise NewError("...") без from exc внутри except теряет исходную причину для diagnose (на самом деле Python всё равно покажет __context__, но это менее явно).
• Широкий try — пять операций в одном try, и непонятно, какая упала.
• return/break/continue в finally молча проглатывает текущее исключение.
• Использование исключений вместо if/else в горячем коде — overhead заметен.
• Очередь except: специфичные типы пишите раньше широких, иначе верхний поймает всё.

• Не различать except, else и finally.
• Не знать raise from.
• Глотать исключения без логирования или действия.

• Объясняет propagation по стеку.
• Понимает traceback.
• Знает chaining через raise from.