问题的历史
在Python 2.5之前，try...finally和try...except作为互斥的语法块存在，迫使开发人员笨拙地嵌套它们，以实现错误处理和清理。PEP 341统一了这些构造，建立了现代保证，即无论try块如何退出，finally都是执行的。这一演变对于在缺乏确定性析构函数的语言中实施可靠的资源管理模式至关重要。
问题
开发人员常常假定显式的return、break或continue语句会立即终止当前作用域，可能会绕过后续的清理代码。如果没有强制执行finally块的执行，在try块内获得的资源（如文件句柄、数据库连接或锁）在早期返回时将会泄漏。这会导致生产系统中的资源耗尽、死锁或数据损坏。
解决方案
Python的编译器将try...finally翻译为特定的字节码指令——SETUP_FINALLY、POP_BLOCK和END_FINALLY——将清理处理程序推送到解释器的执行框架中。当遇到return时，解释器将返回值推送到值栈，执行finally块的字节码，然后处理待处理的返回。如果finally块本身执行return或引发异常，那么这种新的控制流将替代原始的控制流，确保清理优先执行。
def process_file(path): f = open(path, 'r') try: data = f.read() if not data: return None # Finally仍会执行！ return data.upper() finally: f.close() print("清理完成")
问题描述
一个处理财务交易的微服务在高负载下偶尔耗尽其数据库连接池。调查发现泄漏源于一个辅助函数，该函数获取连接，检查缓存，如果缓存命中则提前返回。开发人员将conn.close()调用放在函数的末尾，假设它总会被执行，但早期返回完全绕过了它。
解决方案1：手动清理重复
团队考虑在每个return语句之前复制conn.close()调用。这被拒绝，因为维护性差，因为未来的修改可能会增加新的退出点，而且重复的代码违反了DRY（不要重复自己）原则。此外，这种方法增加了视觉混乱和维护期间发生人为错误的风险。
解决方案2：上下文管理器
他们评估了重构以使用with get_connection() as conn:。虽然符合习惯用法，但这需要修改外部连接工厂以支持上下文管理器协议，而风险超过了需要立即部署的热修复的好处。
解决方案3：Try-finally包装器
选定的方法将连接逻辑包装在try...finally块中。这一最小的更改保证conn.close()在任何返回之前执行，而无需重构依赖关系。它提供了即时安全，并清楚地向未来的维护者传达了清理保证。
结果
修复在部署后数小时内消除了连接泄漏。此模式随后通过代码库中的所有资源获取函数的linting规则进行强制。这防止了类似的回归，并在高峰负载下稳定了服务。
finally块能否修改或抑制函数的返回值？
可以。如果finally块包含自己的return语句，它将覆盖try或except块生产的任何值。原始返回值将被完全丢弃。此外，如果finally块引发异常，则该异常将替代来自前面块的任何异常或返回值，从而有效地压制原来的结果。
如果try块中引发的异常，finally块也引发异常，会发生什么？
原始异常通过屏蔽而丢失。Python从finally块引发异常，初始异常的回溯将被丢弃，除非明确捕获。为了防止这种情况，finally块应该避免可能引发异常的操作，或者在finally中使用嵌套的try...except来优雅地处理清理错误，同时保留原始异常的上下文。
是否有任何情况下finally块保证不执行？
虽然Python的语言语义保证了在正常控制流下finally的执行，但某些灾难性事件会绕过它。如果操作系统发送了无法捕获的信号（如SIGKILL），如果调用os._exit()，或者如果Python进程因段错误崩溃，解释器会立即终止而不执行待处理的finally块。此外，try块中的无限循环或死锁将完全阻止到达finally子句。