Python 上下文管理器中的异常传播机制

__exit__ 返回 true 则吞掉异常，否则异常继续传播；参数全为 none 表示无异常；若其内部再抛异常，原异常被设为 __context__ 并默认压制。

with 语句里抛异常，__exit__ 怎么处理

异常在 with 块中抛出后，会先传给上下文管理器的 __exit__(exc_type, exc_value, traceback) 方法。这个方法的返回值直接决定异常是否继续向上冒泡：返回 True 表示“已处理”，异常吞掉；其他任何返回（包括 None、False、0）都等价于没处理，异常照常传播。

常见错误是以为只要写了 __exit__ 就自动捕获异常——其实它默认什么都不做，只是个钩子函数。

• __exit__ 的三个参数全为 None，说明 with 块正常结束，没异常
• 如果 __exit__ 中又抛了新异常，原异常会被压制（__suppress_context__ = True 效果），只报新异常
• 想记录日志但不拦截异常？别 return，只做日志，末尾不写 return 或显式写 return None

contextlib.suppress 和手动写 __exit__ 的区别

contextlib.suppress 是个现成的“静默指定异常”的上下文管理器，用法简单：with suppress(ValueError): int("abc")。但它只对构造时传入的异常类型生效，且内部 __exit__ 直接返回 True，不做任何额外逻辑。

手动实现时，你得自己判断 exc_type 是否该忽略，还要注意类型匹配细节（比如继承关系、元组传参）。

立即学习“Python免费学习笔记（深入）”；

• suppress(TypeError, ValueError) 等价于检查 issubclass(exc_type, (TypeError, ValueError))
• 手动实现若漏判 exc_type is None，可能在无异常时误触发清理逻辑
• suppress 不支持异常后做资源重试或降级，这类需求必须手写 __exit__

嵌套 with 时异常从哪一层开始传播

异常按 with 块的嵌套顺序，从最内层向外逐个调用 __exit__。每层都有一次“是否吞掉异常”的机会。一旦某层 __exit__ 返回 True，外层就收不到这个异常了。

容易踩的坑是以为外层能“兜底”所有内层异常——其实只要内层吞了，外层根本不知道发生了什么。

• 调试时可在各层 __exit__ 打印 exc_type，确认异常是否被提前截断
• 多个资源需原子性释放（如数据库事务 + 文件锁），不要依赖嵌套 with 的传播顺序，应合并到一个管理器里统一控制
• 使用 contextlib.ExitStack 动态添加上下文时，__exit__ 调用顺序是逆序（后进先出），和书写顺序相反

__exit__ 里再抛异常，原异常去哪了

如果 __exit__ 自己抛出异常，python 会把原异常设为新异常的 __context__，并默认压制原异常的 traceback（除非显式设置 __suppress_context__ = False）。这时候你看到的只有新异常，原异常藏在 __cause__ 或 __context__ 里。

这在调试时特别容易迷惑：日志里只报了“关闭文件失败”，但真正的问题其实是前面的解析错误。

• 想保留原始异常的完整信息，别在 __exit__ 里直接 raise，改用 raise new_exc from original_exc
• 用 traceback.print_exception() 手动打印 original_exc 时，注意传的是 exc_value，不是 exc_type
• 生产环境避免在 __exit__ 中做可能失败的 I/O 操作（如网络请求），否则大概率掩盖真正问题

异常传播机制本身不复杂，难的是在多层清理、动态上下文、错误恢复策略交织时，准确预判哪一层的 __exit__ 实际起了作用。真出问题时，别猜，直接在每个 __exit__ 开头加一行 print(f"exit: {exc_type}")。