写Java的人几乎没有没被异常坑过的。空指针、数组越界、类型转换失败这些是入门课可真到生产环境你面对的多半是异常被catch住之后日志里只有一排堆栈或者一段业务报了错你怎么都查不到最初的根因再或者线上接口突然慢到让人发慌查下来发现高频路径里有人在拿“异常”当“业务流程跳转”用。这篇文章从一个写后端多年的角度把Java异常体系里一些容易被忽略的设计细节、实际项目里反复出现的错误用法、以及我自己踩过之后才想明白的坑系统地梳理一遍。内容不追求面面俱到但每一条都是能用在工作里的实在经验适合刚入行的同学也适合写了两三年Java但没系统复盘过异常处理的开发者。1. 异常体系底层的三个设计取舍从Throwable到不可忽视的抛错成本1.1 Throwable的子类划分逻辑为什么Error不该被“碰”Java里所有异常对象的根都长在Throwable这个类上它往下分成两支Error和Exception。这两个分支最大的区别不在字面上而在背后表达的语义Error代表的是JVM和运行环境层面的严重问题StackOverflowError、OutOfMemoryError都属于这一类Exception才代表程序逻辑层面可以预期、可以恢复的问题。但我在实际评审代码时见过不止一次有人用catch (Throwable t)来“兜底”目的是防止任何异常把程序搞挂。这样做的问题在于当你接住一个OutOfMemoryError之后你接下来能做的操作多半还是要去分配内存结果大概率继续抛同样的错误比不接更糟。而且Error被接住后系统往往已经处于不健康状态了程序继续往下跑只是带病运行后面会出现更诡异、更难排查的问题。一个让我印象很深的例子是某次线上批量任务有人发现任务因为NoClassDefFoundError断了于是加了一个大范围catch (Throwable)把错误记下来然后放过去。结果就是同一条任务在后续几百条数据里连续报错、连续“被放行”日志里堆满了无意义的堆栈并且真正需要关注的“类版本冲突”这个根因被完全淹没。后来我总结成一句话能捕获的异常最多到Exception为止Error交给JVM能做的只是尽量把系统状态记录下来然后退出而不是想办法继续运行。1.2 受检异常与运行时异常边界到底在哪里Exception下面最值得区分的就是checked exception受检异常和unchecked exception运行时异常精确说是继承自RuntimeException的那部分。受检异常的特点是人如其名编译期强制要求你处理——要么try-catch要么往方法签名上声明throws。运行时异常不需要强制处理编译期完全不拦你。很多同学误解了受检异常的“强制处理”含义以为“编译器要求我catch就说明这个异常一定会发生”。其实不是编译器只是替你做了个“提醒”——这段代码所调用的方法它的作者认为调用方应当对这个异常情况做出某种反应。至于你是不是真的能恢复编译器并不知道。我在实际项目里的感受是受检异常最致命的一点不是它存在而是它经常出现在不该出现的层级。举个例子一个Service的方法里调了RPC可能抛三个受检异常然后这个Service的上层Controller、再上层的一个定时任务框架都跟着要throws或者一路catch一路往外包。代码很快被throws Exception或catch (Exception e) { throw new RuntimeException(e); }占满。这时候受检异常的“强制提醒”就变成了一种监督成本而不是设计约束。1.3 抛异常的隐性成本new一个异常对象到底贵在哪很多人知道异常会影响性能但说不清楚影响在哪。Java创建异常对象的开销大头不在new本身而在于构造时默认会调用fillInStackTrace()把这个时刻的线程栈快照记录下来。栈越深、方法调用越多填充栈帧的代价就越明显。如果把异常当作“业务流程控制”的手段用比如在常规返回前故意抛一个异常来表示“结果不存在”在高频路径上就会造成很直观的吞吐下降。我测过一个不算极端的场景一个平时走if-else判断的方法改成用异常做分流后单线程调用一千万次耗时从几百毫秒涨到几秒。当然不是所有异常创建都那么贵但坏习惯一旦写进高频代码迟早会变成线上事故。如果你在极其特殊、确实需要用异常做流程控制的场景里可以覆盖fillInStackTrace()让栈不填充这种写法能显著降低创建异常的成本。但我对团队的要求是可以了解这个技巧默认不要用因为异常就是异常它承载的是“出了意外”的语义而不是“正常流程分支”的语义。2. 受检异常的天使与魔鬼面一场持续多年的工程之争2.1 受检异常最初的美好构想受检异常是Java从语言层面就对“异常必须被处理”这一想法给出的答案。早期很多传统企业级应用开发者对它评价很高因为编译器强制你直面“文件不存在”“网络连接失败”这一类可预期的问题不容易把错误静默吞掉。我先说它的优点当一个方法对外暴露的受检异常足够少、足够明确时调用方确实能一眼看出这个方法有哪些失败模式。比如一个readFile()方法直接抛出IOException我写调用代码的时候就会立刻想到“文件可能不存在、可能权限不足”这就比一个什么都不抛的方法更透明。2.2 实际项目里受检异常如何被系统性绕过可到了真实工程环境受检异常的执行效果往往和设计初衷打架。核心矛盾在于一个复杂业务流程里的方法不是孤立的它会调用几十个底层方法每个底层方法都可能抛出好几类受检异常。于是最上层的业务代码里要么排列组合出几十个catch块要么全包成throws Exception。我见过最极端的代码是整个Controller层方法签名写着throws Exception一直往上甩异常到了框架层才被兜住遇到这种代码受检异常等于形同虚设。还有一种常见套路是“捕获后立即包装重抛”。某项目的代码里到处是catch (SQLException e) { throw new RuntimeException(e); }这种写法把受检异常转成非受检理论上没有完全吞掉信息但问题是团队成员只在编码时候图省事却从不停下来思考“这个异常到底该在上层哪个位置处理”。结果就是异常从底层一路“包装”到顶层中间被包了五六层排查问题的时候要从最外层的RuntimeException一层层剥开cause链才知道真正发生了什么。2.3 我的取舍参考什么情况下仍然适合保留受检异常聊了这么多受检异常的“罪状”但它并不是一无是处。就我个人的实践当满足以下两个条件时我会保留受检异常而不是转成运行时异常一是异常发生之后调用方确实有明确且可行的恢复动作。比如文件上传时磁盘空间不够调用方可以提示用户清理空间并重试这种场景受检异常提醒就很值得保留。二是异常属于“这一步做不了但换个输入参数就能继续”的类型并且调用方需要强制意识到它的存在。比如解析某个外部配置时格式不合法上游需要感知并决定是忽略还是终止。至于那些“抛出之后就是给中间层路过、最终让全局兜底”的异常我倾向于直接定义为运行时异常。这条取舍标准帮我省掉了很多无谓的try-catch也让真正需要被关注的受检异常变得有存在感。3. 病态代码现场那些看似正常、其实埋雷的异常写法3.1 最经典的吞异常catch住了然后什么都没有做空catch块是最典型、也最容易被新手误以为“处理了”的写法。有些理由是“这里不想让异常打断流程”于是catch (Exception e) { }就诞生了。后果就是异常信息完全消失接口对外表现一切正常只有第二次故障出现时你才从某个不相关的数据错误里间接发现问题。我在上一家公司排查过一个诡异的问题一批用户的订单状态间歇性不同步。代码里有一段回调处理catch里打印了日志看起来不算吞异常但日志打的只有一句固定字符串“回调处理失败”没有异常对象、没有上下文。结果就是日志系统里堆满了同一句话完全不知道是哪批订单、哪个回调、失败原因是什么。这里的问题本质还是“把异常信息弄丢了”。我后来对团队立了一条规矩catch块里可以不处理但必须至少做到三件事之一——记录异常对象、打印关键上下文、重新抛出。三者都做不到就说明你根本不该写这个catch。3.2 finally里做return的返璞归真陷阱另一个我经常在代码评审时看到的问题是finally里的return。看起来无害实际非常危险。写一个经典的例子public boolean process() { try { int result doSomething(); return result 0; } catch (Exception e) { return false; } finally { return true; // 这行会让上面的return全部失效 } }只要触发到finally里的return true无论try里发生了什么、catch里怎么判断方法都会直接返回true。这在业务上可能意味着“即使处理失败上层也以为成功”数据不一致就是这么来的。更隐蔽的场景是finally里本来只是做一个资源清理代码里没有显式写return但在清理方法里不小心写了返回值或者清道方法本身抛了异常覆盖了try中的异常都会造成类似效果。我在某次内存缓存刷新任务里栽过同样的跟头。try里更新缓存失败后被catch捕获本来准备记日志并重试结果finally里做“清理临时状态”的操作抛了个NPE直接把原本的异常顶掉了。那一次排查花了我半天时间后来看待finally块的态度就变成了里面只写不抛异常、无返回值的清理动作。3.3 异常丢失与异步线程里“看不见的坑”多个异常同时发生时的表现也是很容易被忽略的。最典型的就是try块里抛了异常Acatch块处理时又抛了异常B最后JVM打印的堆栈往往是BA就丢了。完整保留A的办法是把A作为B的cause或者用“抑制异常”机制后面讲try-with-resources时会展开但很多人没意识到这回事。异步场景更麻烦。线程池里submit一个任务任务的run方法内部异常如果不被捕获最终会体现在Future.get()调用的时候可如果你压根不调用get异常就默默消失了。所以用线程池执行批量任务时我习惯在任务run方法最外层放一个兜底catch把任务标识、异常堆栈和输入参数摘要一起塞到日志里。参数摘要尤其重要否则几百个任务同时失败你连是哪一条数据触发的都定位不到。4. 资源释放与异常叠加try-with-resources的隐藏细节4.1 手动try-finally释放资源为什么容易漏在Java 7以前手动释放IO资源的标准写法就是try-finally嵌套。比如两个资源就得写两层finally一层关一个流代码丑不说顺序一旦反了容易把底层资源先关掉后上层还试图写数据从而抛出另一个IO异常。而一旦try块和finally块同时抛异常finally里抛出的那个会把try里的异常覆盖掉根源信息直接没了。新一点的代码我已经很少看到纯手写try-finally的但老项目里仍然大量存在。我重构过一段旧代码原来8层嵌套的资源关闭逻辑全部改成try-with-resources之后肉眼可见清爽。用句通俗的话说资源关闭这种和异常强相关、又容易出错的重复劳动最好交给语言特性去处理而不是靠人的记忆力。4.2 suppressed异常被语言设计保下来的“第二现场”try-with-resources的核心设计是每个资源都实现了AutoCloseable接口语法块结束时自动调用close()。它的精妙之处在于处理了“try块和close()同时抛异常”的冲突——如果try块里抛出了异常A然后资源close()又抛出了异常B编译器不会简单粗暴地让B覆盖A而是把B作为A的“抑制异常”suppressed exceptions附加进去。你查日志时能同时看到A和B两处异常还能通过getSuppressed()拿到底层有哪些资源关闭失败。这比手动try-finally丢信息的设计要可靠得多。4.3 close方法本身抛异常时应该怎么处理有try-with-resources之后很多人以为万事大吉但close()本身抛出的异常仍然需要想清楚。比如一个自定义连接池里的连接对象close()时如果发现连接已经被服务端断开可能抛受检异常或运行时异常。实践里我通常遵循一条原则关闭动作如果失败大部分情况不影响主流程的“已成功”结论此时记录日志即可只有关闭失败会导致数据未写盘、连接未归还这类实质影响时才需要把关闭异常合并到主异常里抛出。我知道有人在close()里捕获所有异常之后静默吞掉理由是“反正主业务已经成功了”我不赞同这种全盘吞掉的做法。更稳妥的是至少把日志打出来并统计为基础设施异常指标这样连接池问题不会完全隐形但因为某个close失败就把已经成功的请求标记为失败也不合理。具体是记warn级日志还是统计指标可以根据业务对资源状态的敏感程度去定但绝不能对关闭异常不闻不问。5. 自定义异常与异常编排从能用变成好用的实践5.1 继承Exception还是继承RuntimeException自定义异常时第一个问题就是继承哪个父类。结合第2章讲的取舍我现在的默认选择是继承RuntimeException原因很现实大多数业务异常抛出之后中间层其实没有能力也没有必要处理它们只是层层上抛一直到最外层的全局处理器才统一应答。这种情况用受检异常只会让每个中间方法都多写一行throws。但有一种情况我坚持用受检异常这个自定义异常代表“调用方应该主动处理的业务分支”比如订单状态冲突、余额不足、库存锁定失败。这类异常通常是业务的正常分支结果而不是系统崩溃信号调用方必须感知并决定下一步动作。如果不做成受检异常调用方很容易忽略它把本该走的“失败回滚流程”漏掉。5.2 异常粒度控制错误码和异常类该怎么配比自定义异常最常见的过度设计就是给每一个业务错误都单独建一个异常类。比如“用户名不存在异常”“密码错误异常”“账号锁定异常”各建一个类看起来分离度高实际代码里根本维护不住。正确做法是配合错误码使用一个BusinessException类型内部携带errorCode、message、可能再带一个data字段不同场景通过不同的错误码区分。异常类控制在个位数错误码可以定义成枚举这样上层统一处理器只需要根据errorCode做后续的降级、重试或用户提示不需要针对异常类型写一堆catch分支。5.3 异常信息里该放什么不该放什么异常信息是排查问题的第一手资料写得好不好直接影响定位效率。我见过太多次这样的日志业务异常null连个基本的业务单据号都没有。所以我在团队里定了一个自定义异常的必备字段模板场景哪个模块的哪个操作、业务标识订单号/用户ID/请求追踪号、失败原因一句话、以及相关参数的脱敏摘要。比如throw new BusinessException( pay_callback_order_status_error, 支付回调处理失败, orderId20250101, statusPAID, expectWAIT_PAY );这里有个细节参数摘要至少要带上核心标识符但绝不能把密码、Token、身份证号等敏感原值放进异常信息。脱敏不是可选项而是硬性要求否则异常日志就成了数据泄露的通道。另外错误提示信息是给用户看还是给排查者看要分开。用户侧只关心“哪里错了、能不能重试”排查者需要的是完整堆栈和上下文。我建议自定义异常对外输出时用户提示走固定的message字段而需要记录完整上下文时再单独打日志避免把堆栈直接吐给前端。6. 从异常处理到异常设计我给团队的几点落地建议6.1 先定原则再写代码一个团队如果没有统一异常规范代码风格会很快失控。我建议至少定这么几条原则不允许空catch不允许吞掉异常后不做任何记录不允许在finally里return业务失败优先用错误码业务异常系统异常才用运行时异常上抛全局只有一个统一的异常出口。这些原则看起来简单但每条都是踩坑踩出来的能帮你省掉很多重复沟通。6.2 排查异常时学会逆着cause链走拿到复杂异常后很多人习惯从上往下读堆栈但我更推荐第一时间逆着cause链走到底层。中间层为了包装异常经常会包好几层RuntimeException最外层堆栈往往只反映“哪个模块抛出来的”真正的根因藏在链条最末端。排查线上问题时我一般是先看最外层的异常消息和类名然后一路调用getCause()发现最里层的原始异常再结合上下文字段去定位数据这样比逐层读堆栈快很多。6.3 善用异常来收集指标而不是只用来报错最后提一个进阶思路异常也是很好的监控信号。与其在代码里到处写logger.error不如在一个统一出口处统计异常类型和错误码做成指标。比如某个错误码在短时间内的出现频率突然上升通常意味着线上正在发生某种批量性故障。如果只是散落在各处的日志这类趋势很难被系统感知一旦汇聚到统一指标很多问题就能在用户反馈前主动发现。有的团队已经做到把“每类异常的每分钟次数”作为核心监控项我实践下来效果很好。异常处理这个话题说简单确实简单说深也确实深。我在实际项目里最大的体会是异常并不是只属于“防御性编程”的范畴它其实贯穿了接口设计、代码结构、日志规范、线上监控等一整条链路。如果你现在所处项目的异常代码已经乱成一锅粥不妨从本文提到的几个原则开始逐条落地先把最糟糕的空catch和finally坑填平再慢慢梳理异常粒度和信息规范。等哪天线上故障发生时你能在半分钟内顺着一条完整的异常链路找到根因就会发现之前这些投入真的很值。
写Java的人几乎没有没被异常坑过的。空指针、数组越界、类型转换失败这些是入门课可真到生产环境你面对的多半是异常被catch住之后日志里只有一排堆栈或者一段业务报了错你怎么都查不到最初的根因再或者线上接口突然慢到让人发慌查下来发现高频路径里有人在拿“异常”当“业务流程跳转”用。这篇文章从一个写后端多年的角度把Java异常体系里一些容易被忽略的设计细节、实际项目里反复出现的错误用法、以及我自己踩过之后才想明白的坑系统地梳理一遍。内容不追求面面俱到但每一条都是能用在工作里的实在经验适合刚入行的同学也适合写了两三年Java但没系统复盘过异常处理的开发者。1. 异常体系底层的三个设计取舍从Throwable到不可忽视的抛错成本1.1 Throwable的子类划分逻辑为什么Error不该被“碰”Java里所有异常对象的根都长在Throwable这个类上它往下分成两支Error和Exception。这两个分支最大的区别不在字面上而在背后表达的语义Error代表的是JVM和运行环境层面的严重问题StackOverflowError、OutOfMemoryError都属于这一类Exception才代表程序逻辑层面可以预期、可以恢复的问题。但我在实际评审代码时见过不止一次有人用catch (Throwable t)来“兜底”目的是防止任何异常把程序搞挂。这样做的问题在于当你接住一个OutOfMemoryError之后你接下来能做的操作多半还是要去分配内存结果大概率继续抛同样的错误比不接更糟。而且Error被接住后系统往往已经处于不健康状态了程序继续往下跑只是带病运行后面会出现更诡异、更难排查的问题。一个让我印象很深的例子是某次线上批量任务有人发现任务因为NoClassDefFoundError断了于是加了一个大范围catch (Throwable)把错误记下来然后放过去。结果就是同一条任务在后续几百条数据里连续报错、连续“被放行”日志里堆满了无意义的堆栈并且真正需要关注的“类版本冲突”这个根因被完全淹没。后来我总结成一句话能捕获的异常最多到Exception为止Error交给JVM能做的只是尽量把系统状态记录下来然后退出而不是想办法继续运行。1.2 受检异常与运行时异常边界到底在哪里Exception下面最值得区分的就是checked exception受检异常和unchecked exception运行时异常精确说是继承自RuntimeException的那部分。受检异常的特点是人如其名编译期强制要求你处理——要么try-catch要么往方法签名上声明throws。运行时异常不需要强制处理编译期完全不拦你。很多同学误解了受检异常的“强制处理”含义以为“编译器要求我catch就说明这个异常一定会发生”。其实不是编译器只是替你做了个“提醒”——这段代码所调用的方法它的作者认为调用方应当对这个异常情况做出某种反应。至于你是不是真的能恢复编译器并不知道。我在实际项目里的感受是受检异常最致命的一点不是它存在而是它经常出现在不该出现的层级。举个例子一个Service的方法里调了RPC可能抛三个受检异常然后这个Service的上层Controller、再上层的一个定时任务框架都跟着要throws或者一路catch一路往外包。代码很快被throws Exception或catch (Exception e) { throw new RuntimeException(e); }占满。这时候受检异常的“强制提醒”就变成了一种监督成本而不是设计约束。1.3 抛异常的隐性成本new一个异常对象到底贵在哪很多人知道异常会影响性能但说不清楚影响在哪。Java创建异常对象的开销大头不在new本身而在于构造时默认会调用fillInStackTrace()把这个时刻的线程栈快照记录下来。栈越深、方法调用越多填充栈帧的代价就越明显。如果把异常当作“业务流程控制”的手段用比如在常规返回前故意抛一个异常来表示“结果不存在”在高频路径上就会造成很直观的吞吐下降。我测过一个不算极端的场景一个平时走if-else判断的方法改成用异常做分流后单线程调用一千万次耗时从几百毫秒涨到几秒。当然不是所有异常创建都那么贵但坏习惯一旦写进高频代码迟早会变成线上事故。如果你在极其特殊、确实需要用异常做流程控制的场景里可以覆盖fillInStackTrace()让栈不填充这种写法能显著降低创建异常的成本。但我对团队的要求是可以了解这个技巧默认不要用因为异常就是异常它承载的是“出了意外”的语义而不是“正常流程分支”的语义。2. 受检异常的天使与魔鬼面一场持续多年的工程之争2.1 受检异常最初的美好构想受检异常是Java从语言层面就对“异常必须被处理”这一想法给出的答案。早期很多传统企业级应用开发者对它评价很高因为编译器强制你直面“文件不存在”“网络连接失败”这一类可预期的问题不容易把错误静默吞掉。我先说它的优点当一个方法对外暴露的受检异常足够少、足够明确时调用方确实能一眼看出这个方法有哪些失败模式。比如一个readFile()方法直接抛出IOException我写调用代码的时候就会立刻想到“文件可能不存在、可能权限不足”这就比一个什么都不抛的方法更透明。2.2 实际项目里受检异常如何被系统性绕过可到了真实工程环境受检异常的执行效果往往和设计初衷打架。核心矛盾在于一个复杂业务流程里的方法不是孤立的它会调用几十个底层方法每个底层方法都可能抛出好几类受检异常。于是最上层的业务代码里要么排列组合出几十个catch块要么全包成throws Exception。我见过最极端的代码是整个Controller层方法签名写着throws Exception一直往上甩异常到了框架层才被兜住遇到这种代码受检异常等于形同虚设。还有一种常见套路是“捕获后立即包装重抛”。某项目的代码里到处是catch (SQLException e) { throw new RuntimeException(e); }这种写法把受检异常转成非受检理论上没有完全吞掉信息但问题是团队成员只在编码时候图省事却从不停下来思考“这个异常到底该在上层哪个位置处理”。结果就是异常从底层一路“包装”到顶层中间被包了五六层排查问题的时候要从最外层的RuntimeException一层层剥开cause链才知道真正发生了什么。2.3 我的取舍参考什么情况下仍然适合保留受检异常聊了这么多受检异常的“罪状”但它并不是一无是处。就我个人的实践当满足以下两个条件时我会保留受检异常而不是转成运行时异常一是异常发生之后调用方确实有明确且可行的恢复动作。比如文件上传时磁盘空间不够调用方可以提示用户清理空间并重试这种场景受检异常提醒就很值得保留。二是异常属于“这一步做不了但换个输入参数就能继续”的类型并且调用方需要强制意识到它的存在。比如解析某个外部配置时格式不合法上游需要感知并决定是忽略还是终止。至于那些“抛出之后就是给中间层路过、最终让全局兜底”的异常我倾向于直接定义为运行时异常。这条取舍标准帮我省掉了很多无谓的try-catch也让真正需要被关注的受检异常变得有存在感。3. 病态代码现场那些看似正常、其实埋雷的异常写法3.1 最经典的吞异常catch住了然后什么都没有做空catch块是最典型、也最容易被新手误以为“处理了”的写法。有些理由是“这里不想让异常打断流程”于是catch (Exception e) { }就诞生了。后果就是异常信息完全消失接口对外表现一切正常只有第二次故障出现时你才从某个不相关的数据错误里间接发现问题。我在上一家公司排查过一个诡异的问题一批用户的订单状态间歇性不同步。代码里有一段回调处理catch里打印了日志看起来不算吞异常但日志打的只有一句固定字符串“回调处理失败”没有异常对象、没有上下文。结果就是日志系统里堆满了同一句话完全不知道是哪批订单、哪个回调、失败原因是什么。这里的问题本质还是“把异常信息弄丢了”。我后来对团队立了一条规矩catch块里可以不处理但必须至少做到三件事之一——记录异常对象、打印关键上下文、重新抛出。三者都做不到就说明你根本不该写这个catch。3.2 finally里做return的返璞归真陷阱另一个我经常在代码评审时看到的问题是finally里的return。看起来无害实际非常危险。写一个经典的例子public boolean process() { try { int result doSomething(); return result 0; } catch (Exception e) { return false; } finally { return true; // 这行会让上面的return全部失效 } }只要触发到finally里的return true无论try里发生了什么、catch里怎么判断方法都会直接返回true。这在业务上可能意味着“即使处理失败上层也以为成功”数据不一致就是这么来的。更隐蔽的场景是finally里本来只是做一个资源清理代码里没有显式写return但在清理方法里不小心写了返回值或者清道方法本身抛了异常覆盖了try中的异常都会造成类似效果。我在某次内存缓存刷新任务里栽过同样的跟头。try里更新缓存失败后被catch捕获本来准备记日志并重试结果finally里做“清理临时状态”的操作抛了个NPE直接把原本的异常顶掉了。那一次排查花了我半天时间后来看待finally块的态度就变成了里面只写不抛异常、无返回值的清理动作。3.3 异常丢失与异步线程里“看不见的坑”多个异常同时发生时的表现也是很容易被忽略的。最典型的就是try块里抛了异常Acatch块处理时又抛了异常B最后JVM打印的堆栈往往是BA就丢了。完整保留A的办法是把A作为B的cause或者用“抑制异常”机制后面讲try-with-resources时会展开但很多人没意识到这回事。异步场景更麻烦。线程池里submit一个任务任务的run方法内部异常如果不被捕获最终会体现在Future.get()调用的时候可如果你压根不调用get异常就默默消失了。所以用线程池执行批量任务时我习惯在任务run方法最外层放一个兜底catch把任务标识、异常堆栈和输入参数摘要一起塞到日志里。参数摘要尤其重要否则几百个任务同时失败你连是哪一条数据触发的都定位不到。4. 资源释放与异常叠加try-with-resources的隐藏细节4.1 手动try-finally释放资源为什么容易漏在Java 7以前手动释放IO资源的标准写法就是try-finally嵌套。比如两个资源就得写两层finally一层关一个流代码丑不说顺序一旦反了容易把底层资源先关掉后上层还试图写数据从而抛出另一个IO异常。而一旦try块和finally块同时抛异常finally里抛出的那个会把try里的异常覆盖掉根源信息直接没了。新一点的代码我已经很少看到纯手写try-finally的但老项目里仍然大量存在。我重构过一段旧代码原来8层嵌套的资源关闭逻辑全部改成try-with-resources之后肉眼可见清爽。用句通俗的话说资源关闭这种和异常强相关、又容易出错的重复劳动最好交给语言特性去处理而不是靠人的记忆力。4.2 suppressed异常被语言设计保下来的“第二现场”try-with-resources的核心设计是每个资源都实现了AutoCloseable接口语法块结束时自动调用close()。它的精妙之处在于处理了“try块和close()同时抛异常”的冲突——如果try块里抛出了异常A然后资源close()又抛出了异常B编译器不会简单粗暴地让B覆盖A而是把B作为A的“抑制异常”suppressed exceptions附加进去。你查日志时能同时看到A和B两处异常还能通过getSuppressed()拿到底层有哪些资源关闭失败。这比手动try-finally丢信息的设计要可靠得多。4.3 close方法本身抛异常时应该怎么处理有try-with-resources之后很多人以为万事大吉但close()本身抛出的异常仍然需要想清楚。比如一个自定义连接池里的连接对象close()时如果发现连接已经被服务端断开可能抛受检异常或运行时异常。实践里我通常遵循一条原则关闭动作如果失败大部分情况不影响主流程的“已成功”结论此时记录日志即可只有关闭失败会导致数据未写盘、连接未归还这类实质影响时才需要把关闭异常合并到主异常里抛出。我知道有人在close()里捕获所有异常之后静默吞掉理由是“反正主业务已经成功了”我不赞同这种全盘吞掉的做法。更稳妥的是至少把日志打出来并统计为基础设施异常指标这样连接池问题不会完全隐形但因为某个close失败就把已经成功的请求标记为失败也不合理。具体是记warn级日志还是统计指标可以根据业务对资源状态的敏感程度去定但绝不能对关闭异常不闻不问。5. 自定义异常与异常编排从能用变成好用的实践5.1 继承Exception还是继承RuntimeException自定义异常时第一个问题就是继承哪个父类。结合第2章讲的取舍我现在的默认选择是继承RuntimeException原因很现实大多数业务异常抛出之后中间层其实没有能力也没有必要处理它们只是层层上抛一直到最外层的全局处理器才统一应答。这种情况用受检异常只会让每个中间方法都多写一行throws。但有一种情况我坚持用受检异常这个自定义异常代表“调用方应该主动处理的业务分支”比如订单状态冲突、余额不足、库存锁定失败。这类异常通常是业务的正常分支结果而不是系统崩溃信号调用方必须感知并决定下一步动作。如果不做成受检异常调用方很容易忽略它把本该走的“失败回滚流程”漏掉。5.2 异常粒度控制错误码和异常类该怎么配比自定义异常最常见的过度设计就是给每一个业务错误都单独建一个异常类。比如“用户名不存在异常”“密码错误异常”“账号锁定异常”各建一个类看起来分离度高实际代码里根本维护不住。正确做法是配合错误码使用一个BusinessException类型内部携带errorCode、message、可能再带一个data字段不同场景通过不同的错误码区分。异常类控制在个位数错误码可以定义成枚举这样上层统一处理器只需要根据errorCode做后续的降级、重试或用户提示不需要针对异常类型写一堆catch分支。5.3 异常信息里该放什么不该放什么异常信息是排查问题的第一手资料写得好不好直接影响定位效率。我见过太多次这样的日志业务异常null连个基本的业务单据号都没有。所以我在团队里定了一个自定义异常的必备字段模板场景哪个模块的哪个操作、业务标识订单号/用户ID/请求追踪号、失败原因一句话、以及相关参数的脱敏摘要。比如throw new BusinessException( pay_callback_order_status_error, 支付回调处理失败, orderId20250101, statusPAID, expectWAIT_PAY );这里有个细节参数摘要至少要带上核心标识符但绝不能把密码、Token、身份证号等敏感原值放进异常信息。脱敏不是可选项而是硬性要求否则异常日志就成了数据泄露的通道。另外错误提示信息是给用户看还是给排查者看要分开。用户侧只关心“哪里错了、能不能重试”排查者需要的是完整堆栈和上下文。我建议自定义异常对外输出时用户提示走固定的message字段而需要记录完整上下文时再单独打日志避免把堆栈直接吐给前端。6. 从异常处理到异常设计我给团队的几点落地建议6.1 先定原则再写代码一个团队如果没有统一异常规范代码风格会很快失控。我建议至少定这么几条原则不允许空catch不允许吞掉异常后不做任何记录不允许在finally里return业务失败优先用错误码业务异常系统异常才用运行时异常上抛全局只有一个统一的异常出口。这些原则看起来简单但每条都是踩坑踩出来的能帮你省掉很多重复沟通。6.2 排查异常时学会逆着cause链走拿到复杂异常后很多人习惯从上往下读堆栈但我更推荐第一时间逆着cause链走到底层。中间层为了包装异常经常会包好几层RuntimeException最外层堆栈往往只反映“哪个模块抛出来的”真正的根因藏在链条最末端。排查线上问题时我一般是先看最外层的异常消息和类名然后一路调用getCause()发现最里层的原始异常再结合上下文字段去定位数据这样比逐层读堆栈快很多。6.3 善用异常来收集指标而不是只用来报错最后提一个进阶思路异常也是很好的监控信号。与其在代码里到处写logger.error不如在一个统一出口处统计异常类型和错误码做成指标。比如某个错误码在短时间内的出现频率突然上升通常意味着线上正在发生某种批量性故障。如果只是散落在各处的日志这类趋势很难被系统感知一旦汇聚到统一指标很多问题就能在用户反馈前主动发现。有的团队已经做到把“每类异常的每分钟次数”作为核心监控项我实践下来效果很好。异常处理这个话题说简单确实简单说深也确实深。我在实际项目里最大的体会是异常并不是只属于“防御性编程”的范畴它其实贯穿了接口设计、代码结构、日志规范、线上监控等一整条链路。如果你现在所处项目的异常代码已经乱成一锅粥不妨从本文提到的几个原则开始逐条落地先把最糟糕的空catch和finally坑填平再慢慢梳理异常粒度和信息规范。等哪天线上故障发生时你能在半分钟内顺着一条完整的异常链路找到根因就会发现之前这些投入真的很值。
