使用@contextmanager装饰器时为何需要try-finally？

我疑惑在使用Python的@contextmanager装饰器时，为何官方示例要使用try-finally块。我认为直接在yield语句后调用release_resource(resource)，和官方示例功能完全相同，但肯定忽略了某些要点，想了解其中原因。

官方示例代码：

from contextlib import contextmanager

@contextmanager
def managed_resource(*args, **kwds):
    resource = acquire_resource(*args, **kwds)
    try:
        yield resource
    finally:
        release_resource(resource)

我认为的等效代码：

from contextlib import contextmanager

@contextmanager
def managed_resource(*args, **kwds):
    resource = acquire_resource(*args, **kwds)
    yield resource
    release_resource(resource)

核心区别：异常场景下的资源释放 #

两种写法的差异只在with语句块内抛出异常时才会显现：

• 你的写法中，yield之后的release_resource只有在with块内代码正常执行完毕时才会运行。如果with块里抛出了异常，程序会直接跳出函数，release_resource根本不会被调用，导致资源泄漏（比如文件句柄未关闭、网络连接未断开等）。
• 官方示例的try-finally结构，不管with块内代码是正常结束还是抛出异常，finally块里的release_resource都会被执行，这是资源管理的核心要求——无论操作成功与否，必须保证资源被正确释放。

举个实际的例子：

# 用你的写法实现一个文件管理器
@contextmanager
def managed_file(path):
    f = open(path, 'w')
    yield f
    f.close()

# 使用时抛出异常
with managed_file('test.txt') as f:
    f.write('hello')
    raise Exception("出错了！")

这个例子里，文件test.txt的句柄不会被关闭，因为异常打断了代码执行，f.close()根本没机会运行。

而如果用官方的try-finally写法，f.close()会在finally块里执行，哪怕抛出异常，文件也能被正确关闭。

总结 #

• 正常执行场景下，两种写法效果一致
• 异常场景下，非try-finally写法会导致资源泄漏，这是生产环境中绝对要避免的问题
• try-finally是确保资源可靠释放的标准做法，也是@contextmanager装饰器推荐的写法

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