那是我印象很深的一次线上事故。订单服务在高峰期突然大量请求超时监控面板上一片飘红但进程本身没崩、线程池没满、CPU 内存都正常。我们当时围着日志翻了一晚上最后发现根因在一个看起来人畜无害的catch (Exception e) { }空块里——底层连接池抛出的异常被某段代码吞掉了而业务代码继续往下走直到某个资源彻底不可用才以极其诡异的方式集体失败。从那时候起我才意识到异常处理根本不是“语法会写”这么简单。它是整个软件系统里最容易出问题、也最容易被轻视的一环。这篇就当作 Day 29 的学习笔记把 Java 和 Python 两套主流异常机制放在一起拆开揉碎地聊一遍讲讲异常处理背后的设计动机、两种语言的体系差异、以及真正能上手用的捕获原则。无论你是刚学编程还是已经写了几年业务代码都值得重新对照自己的写法看看。1. 先说一次让我改变认知的线上事故空 catch 块吞掉了什么1.1 事故现场还原那天的表象是所有请求都卡在等待响应最后超时。但进程活着基础监控数据全部正常。因为我们这套服务的错误率监控依赖“进程内被捕获并上报的异常数量”而连接池的异常根本就没被抛出来——它在一个很深的调用链里被吞掉了。复盘时翻到那段代码大概是这样的形态try { SomeClient client pool.borrowObject(); // 业务处理 } catch (Exception e) { // 什么都不做 }我当时盯着这个空 catch 块看了很久。它说明了两个问题第一写代码的人对异常处理几乎没有概念他可能只是为了让代码“能编译通过”第二这种空块比没有 try-catch 更可怕因为它让错误直接消失了监控系统、日志系统全部失效问题被推迟到无法挽回的时候才爆发。1.2 根因异常被“处理”了但问题还在这可能就是异常处理最反直觉的地方你写了一个 try-catch异常确实没有让程序崩溃了但如果你没有把异常信息记录下来没有转化成可观测的信号那这个异常只是“被吞掉”而不是“被处理掉”。真正的异常处理做的是三件事感知错误、保留现场、决定下一步。感知错误指的是异常被捕获后要有日志或监控上报保留现场意味着要打出完整的堆栈信息知道是哪一行代码、经过怎样的调用链触发的决定下一步则是明确这个异常是降级、重试、返回兜底值还是继续向上抛。那次事故之后我在团队里定了一条规矩代码里不允许出现空的 catch 块哪怕是临时调试的代码也必须打日志或者加上 TODO 注释。这条规矩看起来很基础但后来真的救了我们好几次。2. 异常处理到底解决了什么问题从一段不用异常的代码说起2.1 错误码方案的三个致命伤在异常机制出现以前主流错误处理方式是错误返回码。比如函数返回-1表示失败返回0表示成功。这种方式在今天很多底层 C 代码和部分 Go 代码里仍然能看到。假设你要实现一个“读取用户信息并发送通知”的功能用错误码写出来大概是这个样子ERR_OK 0 ERR_NOT_FOUND -1 ERR_SEND_FAILED -2 def get_user(user_id): if user_id 0: return ERR_NOT_FOUND, None return ERR_OK, {id: user_id, name: Alice} def send_notify(user): if not user: return ERR_SEND_FAILED return ERR_OK code, user get_user(10086) if code ! ERR_OK: return code code send_notify(user) if code ! ERR_OK: return code print(done)这种写法有三个很致命的问题。第一错误信息携带能力极差。一个整数 return code 最多告诉你“某类错误”但这个错误是因为参数传错了、还是数据库连不上、还是权限不够全都不清楚。你只能靠日志去猜、去排查。第二错误被漏检的概率极高。每层调用都需要手动判断返回值一旦中间某个人懒得判断错误就静默透传了。大多数出问题的线上 bug 不是“处理错了”而是“根本没处理”。第三正常流程和错误流程混在一起。代码里大量 if 判断把业务逻辑剪得支离破碎。一个小功能写起来都要层层嵌套更别说几百个方法互相调用的大型项目了。2.2 异常机制的设计本质错误也是一条“流程”异常机制最大的贡献是把“错误处理”从“正常业务逻辑”里剥离出来。正常流程只需要关心业务本身出了问题异常会沿着调用栈向上传播直到遇到能处理它的 catch 块。用同样的功能对比一下class UserNotFoundError(Exception): pass class NotifySendError(Exception): pass def get_user(user_id): if user_id 0: raise UserNotFoundError(finvalid user_id: {user_id}) return {id: user_id, name: Alice} def send_notify(user): raise NotifySendError(notify service unavailable) try: user get_user(10086) send_notify(user) except UserNotFoundError as e: # 处理用户不存在的情况比如返回 404 print(user not found:, e) except NotifySendError as e: # 处理通知失败的情况比如先缓存下来稍后重试 print(notify failed:, e)所以异常并不神秘它本质上是“错误传播的一种替代返回路径”。当代码碰到了它无法解决的情况它不再需要一个丑陋的返回值去“层层上报”而是直接打断当前流程把控制权交给调用栈上第一个愿意处理它的人。异常机制还有一个附带的好处它能保证“出问题时一定会沿着调用链传递”。你不去捕获它它就会一直往上抛直到进程退出。这比错误码检查更可靠——你不需要相信每个工程师都会判断返回值因为异常会“强制”你面对错误的存在。当然这也带来了一个新的问题处理不好很容易变成“暴力甩锅”比如在顶层统一 catch 掉所有异常只留下一个“服务繁忙”。这种用法在后面的章节我会展开讲。3. Java 异常体系checked、unchecked、finally 与更现代的清理方式3.1 Throwable、Error、Exception 的边界Java 的异常体系是所有语言里最庞大也最规范的一档。它的祖先类叫Throwable下面分成两个大分支Error和Exception。Error对应的是OutOfMemoryError、StackOverflowError这类 JVM 层面几乎无法恢复的问题。写业务代码的时候原则上不应该去捕获它们原因很简单你捕获了也很难做得比 JVM 更好。这种错误只能记录现场、发出告警然后让进程退出重启交给运维策略来处理。Exception才是我们日常说的“异常”它又可以细分成两类受检异常checked exception比如IOException、SQLException。编译器强制你在方法签名里声明throws或者在调用处显式捕获。也就是说编译器逼你“直面错误”。非受检异常unchecked exception比如NullPointerException、IllegalArgumentException。它们继承自RuntimeException编译时不需要声明方法里想抛就抛不需要调用方提前知道。这个区分是整个 Java 异常体系最值得琢磨的地方也是很多 Java 开发者容易忽略的一点。3.2 checked 与 unchecked为什么 Java 要“强制”你处理异常受检异常的设计初衷是好的对于“可预期的、与外部环境相关的错误”比如文件不存在、网络断开它希望程序员在写代码的时候就必须考虑失败分支。但它实际用起来争议极大一个典型的反例是public void readConfig() throws IOException { Files.readAllLines(Paths.get(app.properties)); }如果你不处理编译直接报错。于是很多人会在不需要关心成败的地方写这样的代码public void readConfig() { try { Files.readAllLines(Paths.get(app.properties)); } catch (IOException e) { // 迫于编译器的压力写的 catch根本不知道怎么处理 } }这恰恰违背了受检异常的初衷。编译器逼你“处理”但业务上可能真的没什么可处理的。所以后来很多框架和团队约定RuntimeException用于业务异常受检异常只保留在 IO、网络、数据库这类基础设施边界。比如 Spring 把很多传统的受检异常如SQLException都转成了DataAccessException这种非受检异常目的就是让业务层不要被一堆无关紧要的 catch 淹没。我的建议是如果你的项目里还有选择余地尽量少发明新的受检异常。业务异常统一继承RuntimeException基础设施层的受检异常在边界捕获后转译上抛。这样调用方只需要关心他真正关心的异常而不是被迫处理一个又一个用法不明的 catch。3.3 try-with-resources 与异常抑制Java 7 引入的try-with-resources是资源管理的里程碑式改进。以前我们写文件流要手动在finally里关流InputStream in null; try { in new FileInputStream(app.properties); // 读文件 } finally { if (in ! null) { in.close(); } }close()本身还会抛IOException一旦 try 块和 close 都抛异常原本的异常就会被 close 的异常覆盖非常难排查。用try-with-resources之后变成try (InputStream in new FileInputStream(app.properties)) { // 读文件 }任何实现了AutoCloseable接口的对象都可以放在 try 后面的括号里JVM 会自动负责关闭。而且它引入了一个很聪明的机制叫“异常抑制”如果 try 块抛异常、close 也抛异常close 抛出的异常会作为“suppressed exception”被附加到原始异常上Throwable.getSuppressed()可以看到全部。这样原始异常永远不会被覆盖。这个细节特别适合用在排查线上问题上。你可以自己写一个小 demo 验证一个自定义的AutoCloseable在close()里手动抛一个新的运行期异常然后看捕获到的完整堆栈会发现两个异常都在。像这些机制Java 官方文档里写得很清楚但真正用过一遍之后才算学扎实。4. Python 异常处理try-except-else-finally 的完整语义与异常链4.1 先分清 BaseException 和 Exception不要误捕 KeyboardInterruptPython 的异常体系比 Java 简洁得多但也更容易让人踩坑。Python 2 时代有个著名的问题裸except:会连KeyboardInterrupt、SystemExit都捕获住。你写了一个 CtrlC 想要终止程序结果被一个不该出现的 catch 吞掉程序卡死只能 kill -9。Python 3 里所有异常类的根是BaseException而日常绝大多数异常继承自Exception。这两个类之间有明确的职责区别异常类典型成员是否应该被业务代码捕获BaseExceptionKeyboardInterrupt、SystemExit、GeneratorExit不应该ExceptionValueError、TypeError、KeyError、RuntimeError应该这是业务异常的主战场自定义异常继承Exception的子类按需捕获所以一个重要的写代码习惯是catch 永远要针对具体异常类尽量不要写裸except:更不要用裸 except 去吞KeyboardInterrupt。你在使用任何异步框架比如 asyncio或协程时尤其要小心这个问题内部信号和取消异常一旦被吞整个控制流都会陷入不可预测的状态。4.2 try-except-else-finally 的执行顺序很多人没搞懂Python 的try-except-else-finally比 Java 的try-catch-finally多了一个else。很多人会忽略 else 块但其实它就是“没有异常时代码该走的路”。完整的执行顺序是这样的执行try块里的代码如果try块抛出了异常按顺序匹配except分支匹配到了就执行对应的except块如果try块没有抛出异常执行else块不管有没有异常最后都会执行finally块finally里通常用来释放资源、关闭连接。举个例子会更直观def demo(x): try: result 10 / x except ZeroDivisionError: print(except: x is 0) else: print(else: result , result) finally: print(finally: cleanup) demo(2) demo(0)输出分别是else: result 5.0 finally: cleanup except: x is 0 finally: cleanupelse块存在的意义是尽量让try块里只放“可能抛异常的那一行操作”而“操作成功之后应该执行的正常逻辑”放到else里。这样可以让代码更清晰防止多行代码混在一起后你不知道异常到底是哪一行引发的。不过实际项目里为了少一层缩进很多 Pythonista 也不一定每处都写 else这个可以按团队风格取舍但要知道有这样一个机制存在。4.3 异常链raise from 让根因不再丢失Python 3 里有个特别优秀的特性叫异常链exception chaining。当你捕获一个异常、再重新抛出另一个异常时Python 会自动把前一个异常挂到后一个异常的__context__属性上。如果你用raise ... from ...显式指定前一个异常会挂到__cause__属性上。看这个例子class ConfigError(Exception): pass def load_config(): try: with open(config.json) as f: return json.load(f) except FileNotFoundError as e: raise ConfigError(config file missing) from e这样外层捕获到的ConfigError完整堆栈里会带着原始的FileNotFoundError信息根因不会丢失。调试的时候简直救命。反过来如果你在 except 块里直接写raise而不带任何参数Python 会原样重新抛出当前正在处理的异常堆栈也会保留。这种重抛和“捕获后立即又抛一个新异常”是不同的前者适合做日志记录后保持原异常类型后者更适合做层与层之间的异常转译。记住转译时用from e把根因带上缓存日志时用exc_infoTrue或直接logger.exception打印完整堆栈这两条是最实用的经验。5. 真正值得抄走的异常捕获原则5.1 捕获精度最小化你 catch 的类型异常处理第一大原则是捕获的粒度要尽量具体不要一上来就catch (Exception e)。越宽的 catch意味着你越不清楚这里会出什么问题也意味着真正的问题容易被掩盖。我见过太多项目里到处是大括号的catch (Exception e)然后统一打印log.error(e.getMessage())。这种写法的最大问题是NullPointerException和SQLException完全是两种性质的问题前者八成是代码 bug后者可能只是网络抖动。你把它俩一起捕获、一样处理代码是稳定了但系统正在给你发错误的信号——你以为网络恢复了就没事其实是 bug 被藏在暗处积累。更推荐的做法是try { orderService.pay(orderId); } catch (PaymentTimeoutException e) { // 明确知道是超时可以重试或提示用户 retryLater(orderId); } catch (PaymentRejectedException e) { // 明确知道是拒绝不需要重试直接展示原因 notifyUser(e.getMessage()); }在 Python 里也是一个道理except 后面尽量写具体异常类多个异常可以用元组try: data parse_response(resp) except (ValueError, KeyError) as e: log.error(parse failed: %s, e)5.2 三个“不要”与三个“要”结合我自己的踩坑经验我给你总结三组非常实用的对照不要空 catch。我之前讲过一次线上事故根源就是空 catch。如果实在不知道该怎么处理那就别 catch让它向上抛至少异常还能被监控到。不要只打e.getMessage()或e.printStackTrace()。printStackTrace打到 stdout 后运维根本不会去翻控制台而只有一句 message 连是哪一行代码出的问题都看不出。要打就打成log.error(业务描述: {}, orderId, e)一定把完整堆栈打出来。不要用异常控制业务逻辑。有些刚入行的同学喜欢在业务代码里用throw new XXXException来表示“流程没走通”然后上层再 catch 后走另一个 branch。这个在底层的迭代器里比如StopIteration是语言惯例允许但业务代码里这么做会让代码可读性极差——别人完全看不出你的“正常流程”是什么。业务上的分支应该用 if/switch 去表达异常留给“不正常”的情况。要有分层转译意识。DAO 层的SQLException不要直接抛到 ControllerController 不应该知道底层是 MySQL 还是 PostgreSQL。应该在一个合适的位置把低层异常转译成业务异常比如UserNotExistException、InsufficientBalanceException并保留原始根因。要有兜底兜得住的能力。异常处理的最高境界不是“永远不崩”而是“该崩的地方早崩、不该崩的地方兜住”。比如外部接口调用超时这个可以兜底重试或降级但订单金额计算出现空指针这个必须让它马上暴露而不是假装没事。要有适当的上报机制。catch 到的异常要接入统一日志体系或错误监控。我自己习惯在项目里加一个全局异常处理器所有未被业务代码 catch 的异常统一收集既保证返回给前端一个友好的提示又不丢失完整堆栈。5.3 关于异常的性能与日志一次真实的性能影响观察很多人担心异常的性能开销觉得 try-catch 会影响执行速度。这里要给个正确的认知Java 和 Python 在“不抛异常”的正常路径上try 块本身的开销非常小小到可以忽略不计。真正有成本的是“抛异常”这个过程——创建异常对象要填充线程堆栈这个fillInStackTrace()在极端高频的路径上确实会产生可见消耗。我曾经在一个 QPS 很高的接口里看到有人用抛异常来表达“参数不合法”这种非常常见的分支。压测时那个接口的 RT 明显偏高把异常改成 if 判断之后性能立刻就回来了。所以这里的结论是异常是给“意外情况”准备的不是给“常规分支”准备的。如果你知道这个 case 会发生得很频繁请用正常控制流去处理而不是随手 throw 一个异常。日志方面还有一个细节值得一提。Python 的logging模块里logger.exception(...)会自动带上当前异常堆栈但只能在 except 块里用logger.error(msg, exc_infoTrue)则可以在任何位置打印当前堆栈。别小看这个差异在线排查问题时“能不能看到堆栈”基本决定了你是花十分钟解决问题还是花一个下午翻源代码。学异常处理这件事我最开始也觉得它太简单不就是 try-catch 吗。直到那场线上事故之后我才真正把它当一门正经功课来补。现在看任何代码我都会习惯性地多问一句这一段如果抛异常会走到哪个分支那个分支会留下什么痕迹被吞掉的异常就是定时炸弹只是爆炸时间未定。希望你从 Day 29 开始把异常处理的存在感拉满——它也许不显眼但一定是区分初级和资深工程师的分水岭之一。