凌晨三点的生产事故

那天晚上，我刚躺下手机就炸了。

运维老张在群里连着发了十几条消息："支付接口超时率飙升到百分之三十了订单全卡住了你在吗？"

我瞬间清醒。说起来，上个月刚上线的支付模块，出了问题。

远程连上服务器，翻日志。

奇怪的事情发生了——日志里什么都没有。说起来，没有报错，没有异常堆栈，只有一条条"支付失败"的业务记录。

我把代码翻来覆去看了三遍，逻辑没问题啊。

再往下翻，看到了这段：

try:
result = third_party_pay
save_order
从except来看。log.error
return False

就这么一段。不过，看起来还挺"安全"的——出错了就记日志、返回失败，挺规范吧？

但就是这个看似"安全"的写法，把我坑得通宵没睡。

因为 except: 这个裸捕获，把所有异常都吞掉了。包括 KeyboardInterrupt,SystemExit。甚至最要命的——内存不足时的 MemoryError.

裸 except 的本质痛点

• No Visibility: 你根本不知道到底捕获了什么。代码里只留下一个“支付失败”的日志，却无法追踪到底是接口返回错误、参数错误还是程序资源耗尽。话说回来，
• No Recovery: 即使是你想要抛出的业务异常。也被无声吞掉，让业务继续执行错误的数据流。
• No Exit Control: 按 Ctrl+C 或 sys.exit 都会被吞掉，导致程序无法及时退出或崩溃。按理说，

那场通宵的教训

我当时花了整整一夜。却什么也没查到，只是看到日志里四个字“支付失败”，却不知背后隐藏着什么真正错误。怎么说呢，从我深刻体会到来看，"一句话记录不足以定位问题".

Python 中三种常见异常捕获写法

再看写法一，裸 except

try:
do_something
从except来看，print

写法二这方面。捕获 Exception

try:
do_something
except Exception:
print

至于写法三，捕获具体异常

try:
do_something
except ValueError:
print

为什么裸 except 会吞掉关键异常？

BaseException
├── SystemExit
├── KeyboardInterrupt
├── GeneratorExit
└── Exception
├── ValueError
├── TypeError
├── AttributeError
├── KeyError
├── RuntimeError
└── ...

• **裸 except** 捕获的是所有继承自 BaseException  的异常，包括程序退出、键盘中断等。
• **except Exception:** 捕获的是所有继承自 Exception  的普通异常，不包括 SystemExit 。 KeyboardInterrupt ,GeneratorExit.
• # 对使用者来说：按 Ctrl+C 却无法停止程序？是裸 except 吞掉它们导致的！如果你想让终端能及时响应中断，请不要使用裸 except.
• 如果你的代码中存在大量不可预知错误。而你又不想失去对程序流程控制的话，就需要更细粒度地处理这些异常，而不是用一个全包围的大兜底。-->这才是我们后面讨论正确做法的前提。--> -->毕竟如果你把所有错误都塞进一个“未知”盒子，你永远也找不到真正的问题根源。--> -->

裸 except 的真实代价

• 信息丢失任何未预期到的内部错误都会被吞掉，从而导致后续逻辑基于假设执行。
• 难以排查调试时看到的是一堆“症状”，而不是根本原因。不过，
• 性能风险比如 MemoryError 被吞掉。你可能误以为业务正常，却正因内存泄漏而崩溃。

示例

场景说明

当 JSON 解析失败、数据库连接丢失、内存不足…，怎么说呢，所有这些情况都可能落入同一个“空字典”的陷阱里。

---

正确写法与实践建议

写法 A：捕获具体异常并提供针对性处理

写法 B：使用 except Exception 并完整记录堆栈信息

写法 C：捕获特定异常后重抛或转化为业务级别错误

常见细节提醒

1. 顺序很关键

   ValueError 永远不会被触发，因为它已被父类 Exception 截断。

   至于正确顺序，

2. else 与 finally 的妙用

   • else: 当没有任何 except 被触发时才执行；
   • finally: 无论是否出现异常。都大概率会执行，用于资源清理。

---

实战建议 &

场景	推荐做法
工具函数 / 库代码	抛出具体可预测的自定义/内置异常；说起来，不要捕获
业务逻辑	捕获具体业务相关异常；话说回来，如需兜底，用 except Exception: 并完整记录
框架 / 顶层入口	一个全局 try/except Exception: 做最终兜底。但务必记录完整堆栈

再看最终一点心声，

永远不要轻易使用裸 。如果真的需要，它也应该伴随以下三个检查：

1. 能否列举出所有可能抛出的可预期错误？
2. 每个错误应有对应且明确可恢复或报警方案？
3. 如果出现未知错误，你是否能立刻获取堆栈与上下文？

这样才能让“调试”从仅仅是看日志变成快速定位、修复并调整整个程序的一部分。

---

结束语这方面，

那场通宵让我明白——一个简单多余字符 : 就能让你的调试之路彻底失控。请牢记这份经验，让未来每一次编码都成为一次更精准、更可控、更高效的问题解决过程。