Python如何优雅为with语句添加异常场景执行的finally逻辑

Python 原生语法不支持直接在with块后挂载finally分支，你现在用的try包裹with再加finally的写法是标准原生方案，虽然多一层嵌套，但执行无额外开销、语义明确，所有Python开发者都能快速读懂，是生产环境的首选写法。
如果想减少嵌套层级，把逻辑收拢在同一代码块，可以通过标准库提供的上下文管理器工具实现等价效果，不需要修改Python语法。

方案1：仅在with块抛出异常时触发回调（完全匹配你的需求） #

你的核心需求是仅当代码执行抛异常时执行自定义逻辑，正常运行时不触发，同时不影响with自带的资源关闭逻辑，可以用contextlib.contextmanager实现一个通用的异常钩子：

from contextlib import contextmanager

@contextmanager
def run_on_error(callback):
    try:
        yield
    except Exception:
        callback()
        raise  # 原样抛出原异常，不吞错、不中断异常传播

使用时直接和原有资源的上下文管理器写在同一个with行即可，没有额外嵌套：

with open(path, 'w') as f, run_on_error(do_something_else):
    doing_something(f)

逻辑特性：

• 文件的正常关闭完全由open自带的上下文管理器保障，和自定义回调逻辑完全解耦
• 只有doing_something(f)抛出异常时，才会执行do_something_else()，执行完成后原异常会正常向上抛出
• 代码无异常正常跑完时，不会触发回调

方案2：实现和原生finally完全一致的语义 #

如果你需要无论代码块是否抛异常都执行收尾逻辑（和你举例的try...finally效果100%等价），只需要调整上下文管理器的实现即可：

from contextlib import contextmanager

@contextmanager
def run_always(callback):
    try:
        yield
    finally:
        callback()

使用方式和上面完全一致：

with open(path, 'w') as f, run_always(do_something_else):
    doing_something(f)

关于「Python为什么不原生支持该语法」的说明 #

with语句的设计定位是封装单个/多个上下文资源的获取与释放逻辑，把资源相关的收尾逻辑收敛到上下文管理器内部；而跨逻辑块的通用收尾、异常触发自定义动作本身就是try/except/finally语法的职责。如果给with增加finally分支，会模糊两个语法的语义边界，反而提升代码的理解成本，因此这个语法提案一直没有被Python官方采纳。
如果你的回调逻辑需要接收异常对象、按异常类型做分支处理，只需要给上面的上下文管理器增加对应参数即可，扩展成本极低。

内容的提问来源于stack exchange，提问作者redseven