Python with 内报错却显示成功：用 contextmanager 排查吞异常

Python 脚本里，with 内部明明报错，日志也记录了异常，最后却进入成功分支。先别怀疑调度器：资源包装器可能把错误吞了。下面用 Python 3.8+ 的同步示例，拆开异常传播、资源清理和业务验收，找出“有错误日志却显示成功”的原因。

一、with 负责退出流程，不保证错误向外传播

with 并不只是自动执行 finally。它先调用上下文管理器的 __enter__，进入代码块；块内发生异常时，把异常类型、对象和 traceback 交给 __exit__。退出方法可以决定是否压制这个异常。

类式管理器的 __exit__ 返回真值，异常就被压制，程序从 with 后面继续。返回 None 或 False，异常继续传播。这里看的是“真值”，不只字面上的 True；误返回非空字符串或对象也值得检查。没有异常的正常退出，返回值不会改变控制流。

二、用十几行复现日志与结果打架

将下面代码保存为 demo.py，用 python3 demo.py 运行。它只操作内存，不连接数据库，也不改生产文件。第一段故意保留错误，方便观察。

from contextlib import contextmanager

@contextmanager
def 资源范围():
    try:
        yield
    except ValueError as 错误:
        print("已记录：", 错误)
        # 反例：这里没有重新抛出
    finally:
        print("已清理")

with 资源范围():
    raise ValueError("业务失败")
print("错误地走到成功分支")

输出包含“已记录”“已清理”，最后仍出现“错误地走到成功分支”。ValueError 确实发生了，但外层没有收到它。只看日志有没有报错，无法判断调用方拿到了什么失败信号。

三、为什么 @contextmanager 会吞掉这次异常

装饰器把生成器包装为上下文管理器。执行到 yield 时，把控制权交给 with 内部；内部抛错后，错误会在生成器的 yield 位置重新抛出，因此包住 yield 的 except 可以捕获它。

如果只是为了记录日志，却让生成器正常结束，没有重新抛出错误，包装器会认为异常已经处理。这个行为和“处理器只打印一行日志”不是同一回事：你同时改变了调用方的控制流。

注意：生成器函数本身的 return False 不是类式 __exit__ 的返回 False。捕获后 return False 仍是正常结束，不能靠这个值恢复异常传播。需要保留失败时，用不带参数的 raise。

四、记录后 raise，成功分支只留给正常路径

修复时，把 raise 放在捕获分支，finally 只负责资源收尾。下面用内存字典模拟关闭状态；实际工程替换为该资源的关闭操作。

from contextlib import contextmanager

@contextmanager
def 资源范围(状态):
    try:
        yield 状态
    except Exception as 错误:
        print("已记录：", type(错误).__name__)
        raise
    finally:
        状态["已关闭"] = True

状态 = {"已关闭": False}
try:
    with 资源范围(状态):
        raise ValueError("业务失败")
except ValueError:
    print("外层确认失败")
else:
    print("业务成功")
print("清理状态：", 状态["已关闭"])

这一段会输出“外层确认失败”和清理状态 True，不会输出“业务成功”。except Exception 在这里仅记录后立即重抛，不把未知程序错误转成正常值；如果无需附加日志，只保留 try/finally 更简单。

例子中的外层捕获是为了展示结果。实际 CLI 如果捕获错误后直接返回，进程仍可能退出为 0；应让错误继续传播，或由顶层明确返回非零退出码。服务接口也应返回约定的失败结果，不把一条错误日志当作完成验收。

五、允许忽略时，把范围缩到最小

有时压制异常是业务要求，例如清理一个可选临时文件时，“本来不存在”可以接受。这时使用 contextlib.suppress(FileNotFoundError)，并把范围限于那一个删除操作，不要把整段任务包进 suppress(Exception)。

不存在和没有权限不是同一件事。PermissionError、数据格式错误、网络故障仍应暴露。若任务允许某项失败，最好保存目标与错误类别，输出明确的部分失败结果，不能让“没有 traceback”代替“全部成功”。

内层已压制错误时，外层管理器会看到正常退出。事务类包装器尤其要小心：是否提交取决于其协议和业务检查，不能指望外层自动发现早已被内层吃掉的异常。with 不会凭空撤销已经发送的消息或写入的外部数据。

六、清理也会失败，别把原错误弄丢

finally 中的关闭操作若抛出新异常，外层可能收到清理错误，而不是最初的业务错误。原异常通常保存在新异常的 __context__ 链中；排查时要看完整 traceback，不只复制最后一行。

清理失败是否优先上报、是否同时保留业务失败，需要约定。不要加 except: pass 一概掩盖，也别在 finally 里 return 来强行报成功。涉及真实连接、事务或文件系统时，应单独注入清理失败，确认错误与资源状态都可追踪。

@contextmanager 的生成器必须恰好 yield 一次。进入前没有 yield、正常退出后再次 yield，都可能触发 RuntimeError。这是包装器协议错误，不是业务已经成功；同一个生成器式管理器实例也不要重复进入。

七、故障分支对照表

先画出异常穿过的包装层，再逐层注入错误；不要一次改掉所有处理器。

八、用失败路径验收，不只跑通正常路径

验收清单：正常任务能完成；业务异常能到达调用方；清理在成功与失败路径都执行；异常实例与业务 traceback 保留；允许压制的类型精确；权限错误不误吞；清理失败有完整异常链；外层不会把部分失败记为完整成功。

本文在 Python 3.14.3 的独立内存实验中完成 13 项检查，覆盖生成器吞异常、裸 raise、类式真值、内层压制、清理失败和 yield 协议，并再次执行两段最终正文代码。未验证真实数据库提交、连接关闭或外部副作用，不能把模拟清理当成生产验收。

这不是新版本功能，而是同步上下文管理器的长期语义。资源关好了，与任务做成了，是两份不同的成绩单。

参考资料：Python 官方：contextlib；PEP 343：with 语句。