Python 在 finally 中 return，未处理的异常没有传给调用方

函数的 try 中已经执行了 raise，没有任何 except 捕获它，调用方却仍收到一个正常返回值。若 finally 中有 return，应检查这条退出路径：它会丢弃暂存的异常，也可能覆盖 try 原本准备返回的值。

这不是添加 finally 本身就会吞异常，而是执行了从中退出函数的 return。CPython 3.14 还会对这种写法产生 SyntaxWarning；警告并没有把旧行为改成自动重新抛出异常。

用最小调用链确认异常在哪里消失

下面是问题结构示例，不依赖文件或网络操作：

def read_value():
    try:
        raise ValueError("invalid value")
    finally:
        return "fallback"

在允许这段代码执行的环境中，调用 read_value() 会得到 "fallback"，不会收到那次 ValueError。Python 暂存尚未处理的异常，进入 finally 做收尾；但 return 又要求当前函数正常返回，于是异常不再向外传播。

检查真实代码时，应沿着被调用函数回到包装函数，找出 finally 中实际会执行的 return，包括没有返回值的裸 return。它返回的是 None，同样会改变异常路径。不要只检查 except 中是否写了 pass。

保留清理，把返回值放回成功路径

若要求失败继续抛给调用方，让 finally 只做清理。下面的函数接收两个已定义的回调：operation 完成工作并返回结果，cleanup 执行收尾。

def run_with_cleanup(operation, cleanup):
    try:
        return operation()
    finally:
        cleanup()

operation() 成功时，先保存它的返回值，执行清理后再返回。它失败时，清理仍会执行；只要清理正常结束，原异常就继续向外传播。

也可以把成功结果赋给局部变量，把 return result 放在整个 try / finally 后面。关键是不要从 finally 强行结束控制流；无需把正常的清理代码一并删除。

清理本身仍可能失败。如果 cleanup() 抛出另一个异常，调用方会看到这个新异常，原异常作为它的上下文保留。修复之后看到不同的异常类型时，应继续检查异常链，而不是再加一个返回默认值把它盖住。

确实需要默认值时，只处理约定的异常

如果接口约定对某一种失败返回默认值，可以在对应的 except 中明确表达：

def run_or_default(operation, cleanup):
    try:
        return operation()
    except ValueError:
        return "fallback"
    finally:
        cleanup()

这个例子只把 operation() 的 ValueError 转成默认值。其他异常在清理后仍应传播；清理失败也不会被同级的 except ValueError 自动处理。真实项目应把异常类型和返回值换成接口约定，不能为了让所有测试都“成功”就扩大为捕获所有异常。

区分版本警告与运行结果

CPython 3.14 会在构建语法树时，对从 finally 跳到外部的 return、break、continue 发出警告。预编译代码的使用者不一定在每次执行时看到它，因而“终端没有警告”不能证明写法安全。将警告视作错误的环境也可能直接阻止代码运行。

限制针对的是离开这个 finally 的控制流。定义在其中的内层函数拥有自己的 return，或者只跳出其中一个内层循环的 break，不能仅凭关键字位置相近就一律删掉。检查时要看退出的是哪一层。

修复后分别覆盖成功返回、预期异常、其他异常和清理失败四条路径：确认返回值未被覆盖、清理确实执行，以及异常按接口约定到达调用方。异常重新暴露后，上层可能触发重试或告警，部署前需核对这些行为。若撤回变更，应保留失败记录并处理调用方约定，不要把重新隐藏异常当成业务已经恢复。