为null：异常信息丢失的六类场景与排查工具)
e.getMessage() 打出来是 null日志里只剩孤零零一行java.lang.NullPointerException或者干脆就是个空格子这是我在无数技术讨论里见得最多的一类求助。程序明明抛了异常catch 也进去了偏偏拿不到一句人话排查起来就像在黑屋子里找开关。这篇文章就围绕 e.getMessage() 拿不到错误信息这件事往下拆从 Throwable 内部的存储结构到异常被包装、被框架翻译、被日志框架吞掉、被线程池藏起来、被 JIT 优化抹平这五种典型路径再到一套可以直接抄走的排查流程和工具方法。不管你是刚写第一个 try-catch 的新手还是天天在线上捞日志的老手这里面的坑大概率你都踩过至少两个。1. 先把地基打牢e.getMessage() 里的那段字符串到底是什么1.1 Throwable 内部其实只存了一个 detailMessage 字段很多人下意识觉得异常对象是个信息很丰富的东西里面应该有错误码、错误描述、发生位置、上下文参数。实际上翻开 JDK 源码你会发现Throwable 里跟描述相关的成员少得可怜核心就是一个private String detailMessage外加一个cause指向上一层异常再加一个StackTraceElement[]数组记录调用栈。getMessage()做的事情简单到令人失望——原样返回那个detailMessage字段字段是 null 就返回 null不做任何兜底、不做任何加工、不会去猜你想要什么。这就意味着一个残酷的事实异常信息里有没有内容完全取决于这个异常对象在被 new 出来的那一刻有没有人给它传字符串。传了就有没传就是 null后面任何地方都变不出来。所以当你看到 e.getMessage() 为 null第一反应不应该是日志框架坏了而应该是这个异常在构造时就没带消息。理解了这一点很多困惑会瞬间打通。比如为什么空指针异常经常没有消息为什么某些工具类抛出的异常只有类名没有描述为什么同一个接口有时候有提示有时候没有——因为这些异常来源不同有的走的是带参构造有的走的是无参构造中间没有任何统一保证。1.2 getMessage、toString、printStackTrace 三者的取舍既然 detailMessage 可能为 null那为什么有些地方打印出来的异常看起来又有信息了因为toString()做了兜底。它的逻辑大致是取类名再拼上getLocalizedMessage()的返回值如果消息是 null 就只返回类名。所以你打e.toString()或者直接把异常对象拼进字符串至少能看到java.lang.IllegalStateException这样的类型信息比一个 null 强得多。printStackTrace()则是另一条路它把异常类型、消息、完整调用栈一起写到标准错误流格式是人类可读的多行文本。这三者的定位完全不同getMessage()适合给用户看的简短提示toString()适合拼在单行日志里做粗筛printStackTrace()适合本地调试看完整链路。我在做代码评审时经常看到有人用log.error(e.getMessage())这一行日志在生产环境基本等于没打——既没有异常类型也没有堆栈连是哪个类抛的都看不出来。还有一个容易被忽略的成员是getLocalizedMessage()它默认直接调用getMessage()只有自定义异常重写了这个方法才会有差异。如果你的项目里有国际化需求重写它是有意义的如果没有把它和 getMessage() 混用没有实际收益反而会让排查的人多绕一圈。顺带提一句getMessage()返回空字符串和返回 null 是两回事。前者说明构造时传了个空串后者说明压根没传。日志里两者看起来都像没内容但排查方向不完全一样判断时最好用判空工具一起处理而不是简单写if (msg null)。2. 六种典型场景为什么你手里的 message 是空的2.1 异常对象从出生起就没带消息最常见的一类就是异常在创建时走的是无参构造。业务代码里写throw new RuntimeException()、throw new IllegalStateException()、throw new UnsupportedOperationException()的地方非常多尤其是在这个分支理论上不会进来的防御性代码里作者往往图省事不写描述。这类异常一旦真的抛出getMessage()必然返回 null你在上层怎么折腾都拿不到东西。JDK 自己抛的异常也有类似情况。空指针异常在较新的 JDK 版本里会附带一句哪个变量为 null的详细描述但这个能力需要显式开启对应的虚拟机参数早期版本默认是不带的抛出来就是光秃秃一个类名。数组越界、算术异常在正常路径下一般有描述但在被 JIT 优化过之后又会变回裸异常这个后面单独说。还有一种隐蔽情况自定义异常继承了 RuntimeException但只写了带参构造父类构造里没有调用super(message)而是自己存了一个字段。结果getMessage()走的是父类的实现返回 null而你以为信息存在自己的字段里。这种 bug 我在接手别人代码时遇到过两次表现就是明明传了错误描述打出来却是 null对着源码看半天才发现构造函数少了一行。提示判断一个异常是否天生没消息最快的办法是看抛出点的源码。如果那个位置是第三方 jar 里的代码用反编译工具看一眼构造函数调用即可几秒钟的事。2.2 包装时把 cause 丢了第二类是高发区几乎每个项目都有一两处。典型写法是这样的try { doSomething(); } catch (Exception e) { throw new BizException(操作失败); }这段代码把原始异常吞掉了只留下一个自己编的字符串。等这个异常冒到最外层getMessage()返回的是操作失败看起来有内容但对排查毫无帮助——你不知道底层到底是数据库超时、参数非法还是空指针。更糟的情况是连字符串都不写直接throw new BizException()那就真的什么都没有了。正确的写法是把原始异常作为 cause 传进去try { doSomething(); } catch (Exception e) { throw new BizException(操作失败, e); }这样异常链就完整了外层 message 给人看内层 cause 给排查用。判断标准很简单任何一个 catch 块里重新抛出的异常都必须带上原异常引用。我在团队里推行这条规矩时直接在代码检查工具里加了一条规则catch 块内 new 异常但没传 cause 的直接报错效果立竿见影。与之配套的认知是getMessage()永远只返回当前这一层的信息。想看全貌必须顺着getCause()往下走一层层剥直到 cause 为 null。很多人拿不到有用信息不是信息不存在而是只看了一层就放弃了。2.3 框架层的二次翻译如果你用的是带持久层的容器框架会发现数据库原始异常很少能直接冒到业务层中间会被翻译成框架自己的一套异常体系。翻译之后的异常 message 通常是一句很长的英文比如某条语句执行失败真正的数据库错误码、约束名、字段名都藏在 cause 里有时候要往下剥三四层才能看到。反射调用也是重灾区。用Method.invoke()调用目标方法如果目标方法内部抛了异常反射层会把它包成一个InvocationTargetException而这个包装异常的getMessage()往往是 null。真正的异常要用getTargetException()或者getCause()取。我见过有同学在反射调用外面写catch (Exception e) { log.error(e.getMessage()); }日志里一片空白然后怀疑人生地查了两个小时。部分容器框架提供了便捷方法比如取最具体原因的 API能一步跳到异常链末端。这个思路值得借鉴——与其每次手写循环不如在项目里封一个公共方法所有需要展示错误的地方统一调用。2.4 日志侧根本没把 message 写出去到这一步就要怀疑日志本身了。常见的三种写法问题第一种log.error(e.getMessage())。这一行只输出了一个字符串异常对象的类型和堆栈全丢了如果 message 恰好是 null日志框架会打出一个null或者干脆什么都不打。第二种占位符和参数对不上。log.error(处理失败 {}, e)这种写法如果占位符只有一个而参数传了异常对象有些实现会把它当成普通参数做字符串拼接走toString()堆栈就没了。正确姿势是log.error(处理失败, e)异常对象放在最后一个参数位置且不带占位符日志实现会识别出来并打印完整堆栈。第三种配置问题。日志级别设成了 ERROR 但你的代码用的是log.info或者 appender 没配、异步队列满了丢日志、日志文件被切割覆盖。这类问题的特征是偶发同一段代码有时候有日志有时候没有排查时要先确认日志是否真的写到了磁盘而不是停留在内存缓冲区里。我个人的习惯是任何 catch 块里的错误日志第一个参数写固定前缀加关键业务标识第二个参数直接传异常对象绝不在日志语句里调用getMessage()。这样无论 message 是 null 还是有内容堆栈永远都在。2.5 异步链路把异常藏进了 Future用线程池执行任务时如果提交方式是submit()任务内部抛出的异常会被封装进Future不会触发线程的未捕获异常处理器也不会打印任何日志。只有当有人调用future.get()时才会抛出一个包装异常真正的原因在它的 cause 里。如果你提交完就不管了异常就永远静静地躺在那里。execute()的行为不同异常会向上冒到线程的未捕获异常处理器默认会打印到标准错误流但这依赖于你配置了处理器否则可能被静默丢弃。异步编排工具也有类似特性join()和get()抛出的包装类型不一样剥壳的层数也不一样。我一般会在异步任务的入口包一层统一的捕获逻辑把异常完整记录下来再往外抛避免依赖调用方是否记得取值。这件事看起来琐碎但在排查任务跑了但没结果这类问题时能省下大量时间。注意异步场景下getMessage()拿到的往往是包装异常的 message真正的错误描述在 cause 链里。看到包装类型的异常名第一反应就应该是往下一层找。2.6 JIT 优化后的裸异常这一类最反直觉也是很多老手都会愣一下的场景同样的代码、同样的位置前几百次报错日志里堆栈齐全、消息完整某一天之后突然变成一行没有堆栈、没有消息的异常类名重启服务后又恢复正常。原因是虚拟机有一个默认开启的优化参数含义是在快速抛出模式下省略堆栈。当某个位置反复抛出同一类由虚拟机隐式产生的异常空指针、数组越界、算术异常、类型转换异常等并且这段代码已经被即时编译器编译成优化版本虚拟机会认为这个异常太常见了每次都采集堆栈太浪费性能于是改用一个预先分配好的、没有堆栈、没有消息的异常实例直接抛出。这个优化的收益是真的——异常构造里最贵的一步就是填充堆栈高频抛异常的场景下开销非常可观。但代价是排查信息全部丢失。解决办法有两个一是在启动参数里关掉这个优化加上对应的关闭开关适合排查阶段临时使用二是别盯着最新那条日志看往前翻找到第一次出现的那一条那时候堆栈还是完整的。需要强调的是这个优化只影响虚拟机自己抛出的隐式异常代码里throw new XxxException(...)显式创建的不受影响。所以如果你看到 message 为 null 且异常类型是空指针又恰好符合高频重复的特征基本可以锁定是这个问题。3. 实操排查从一行日志挖到根因3.1 第一步分清是 null 还是没打出来拿到没有错误信息这个现象先别急着改代码花两分钟做个区分。做法是把那行日志改成同时输出三样东西异常类名、getMessage()的原始返回值、以及完整堆栈。如果类名和堆栈都有只有 message 是 null那就是 2.1 或 2.2 的问题如果连堆栈都没有那大概率是 2.4 的日志写法问题或者 2.6 的优化问题如果堆栈里出现了一个包装类型的异常那就是 2.3 或 2.5。这个区分动作看起来多余实际上能省掉大量无效尝试。我见过有人一上来就怀疑日志框架折腾了半天配置文件最后发现是代码里throw new RuntimeException()没写消息跟日志一毛钱关系没有。区分清楚之后把范围缩小到具体的某一层再往下钻就快多了。3.2 第二步写一个能挖穿异常链的工具方法与其在每个 catch 块里手写循环不如一次性封一个方法项目里所有需要展示错误的地方都调它。核心逻辑是顺着 cause 往下走同时做好三件事防自引用死循环、限制最大深度、把每一层的类名和消息都拼出来。public final class ExceptionUtils { private static final int MAX_DEPTH 20; public static String dump(Throwable root) { if (root null) { return null; } StringBuilder sb new StringBuilder(256); SetThrowable seen Collections.newSetFromMap(new IdentityHashMap()); Throwable cur root; int depth 0; while (cur ! null depth MAX_DEPTH) { if (!seen.add(cur)) { sb.append( (检测到循环引用停止)); break; } sb.append([).append(depth).append(] ) .append(cur.getClass().getName()) .append(: ); String msg cur.getMessage(); sb.append(msg null ? (message 为 null) : msg) .append(System.lineSeparator()); cur cur.getCause(); depth; } return sb.toString(); } }几个细节值得说明。用IdentityHashMap而不是HashSet是因为异常对象没有重写equals用普通集合虽然也能工作但语义上应该按对象身份判断避免某些重写了 equals 的自定义异常造成误判。限制最大深度是为了防止异常链异常长导致日志爆炸二十层在绝大多数场景下绰绰有余。把 null 显式标注成 (message 为 null) 而不是留空是为了让看日志的人一眼分辨没消息和消息是空串。这个工具方法我建议放在项目的公共基础模块里命名统一所有业务模块依赖它。团队里推广之后最直观的变化是排查问题时不再需要让人重新发版加日志现有日志里就能看到完整链路。3.3 第三步反射与 RPC 场景的兜底反射调用的地方catch 块要专门处理InvocationTargetException取出目标异常再走上面的工具方法。如果目标异常本身又是包装的工具方法会自动往下剥不用额外操心。跨进程调用的情况更麻烦一些。异常信息在经过序列化传输后通常只保留类名和消息堆栈会丢失某些实现下消息字段为空还会被序列化成 null。这时候接收端拿到的异常看起来什么信息都没有但发送端的日志里其实是完整的。排查这类问题时一定要两边日志对着看先确认发送端有没有把异常信息组装好再看接收端有没有正确反序列化。还有一个细节部分框架在异常消息为空时会用默认文案填充导致你以为拿到了真实信息实际上是框架编的。判断方法是看这条消息是否在所有同类错误里都一模一样如果是那基本就是框架兜底的文案不是真实原因。3.4 第四步日志侧的四项自检排查到最后把日志配置过一遍重点看四件事。第一错误日志的写法是否符合规范异常对象是否作为最后一个参数传入且不带占位符。第二日志级别是否匹配确认那条语句在线上环境真的会输出。第三appender 配置是否完整有没有因为异步队列容量不足而丢弃日志的情况这一点在流量高峰期特别容易出现。第四日志文件是否被正确滚动和保留有没有出现当天的日志文件里查不到问题这种尴尬。这四项过一遍大概五分钟但能排掉相当一部分日志里什么都没有的假象。我自己就遇到过一次排查了半天代码最后发现是异步日志队列满了开始丢弃把队列容量调大之后问题自动消失。4. 从源头堵住编码阶段的几条硬规矩4.1 自定义异常的最小正确写法自定义异常看着简单写错的概率却不低。我总结的最小正确形态包含三部分继承合适的父类、提供带消息和带 cause 的构造、把消息原样交给父类。public class BizException extends RuntimeException { private final String code; public BizException(String code, String message) { super(message); this.code code; } public BizException(String code, String message, Throwable cause) { super(message, cause); this.code code; } public String getCode() { return code; } }关键在于super(message)和super(message, cause)这两行。少了它们消息就存不进父类的字段getMessage()自然是 null。有些同学喜欢自己定义一个msg字段然后重写getMessage()返回它这也行得通但多了一层间接容易被后来的维护者忽略不如直接交给父类省事。另外提醒一句自定义异常不要重写fillInStackTrace()除非你非常确定性能是瓶颈。有些文章教人为了性能把它改成空实现结果堆栈全没了排查时哭都来不及。真要优化也应该只在明确测量过开销、且该异常用于流程控制的场景下才考虑。4.2 统一异常出口的包装规范一个成熟的业务系统异常最终都会汇聚到一个统一出口由它决定返回给调用方什么、记录什么日志。这个出口的包装逻辑决定了你后续能不能拿到有效信息。我的做法是分三层最内层保留原始异常不动中间层按业务语义包装并带上 cause最外层负责记录完整链路和转换对外响应。包装时消息要写清楚在做什么事的时候失败了而不是笼统的系统错误。比如生成订单快照失败就比操作失败有用得多至少能定位到模块。对外响应里不要直接暴露原始异常消息尤其是数据库相关的既有安全风险也不友好。正确做法是把异常码和一段面向用户的提示返回出去完整的异常链只写进日志。这两条信息通道分开是很多团队踩过坑之后才建立的规范。4.3 提示语与错误码的分层设计消息内容本身也值得设计。我一般把消息分成两类给用户看的和给开发看的。给用户看的要短、要可行动比如手机号格式不正确给开发看的要包含定位信息比如用户注册校验失败字段 phone值长度 13期望 11。这两类信息可以同时存在于异常链的不同层外层是用户提示内层是技术细节。展示时按场景各取所需日志里全量输出接口响应里只取外层。还有一个实践是给每类异常配一个稳定的错误码。有了错误码即使消息因为各种原因丢失也能通过码值反查原因。这在跨团队协作时尤其有用——对方只需要报一个码你就能定位到具体的分支逻辑不用猜。5. 常见问题速查与踩坑记录5.1 一页速查表现象最可能原因快速验证方式处理方向message 为 null堆栈完整异常是空指针异常构造时未传消息看抛出点源码是否用无参构造补消息或改用带参构造message 有内容但是笼统的操作失败catch 后重新抛异常未带 cause搜索 catch 块里的 new 语句补上 cause 参数日志里只有一行类名没有堆栈日志语句只传了 getMessage()检查日志写法异常对象作为最后一个参数传入堆栈里有 InvocationTargetException反射调用包装看异常类型名取 getTargetException 后再处理前几次有堆栈后面突然没有虚拟机快速抛出优化往前翻最早的报错记录排查期关闭优化或看早期日志异步任务失败但无任何日志用了 submit 且未取结果检查提交方式换成 execute 或在任务内捕获跨进程调用后消息为空序列化时丢失对比两端日志两端都记录完整异常链日志偶发缺失高峰期更明显异步 appender 队列满丢弃查看日志框架内部状态调大队列或改同步输出这张表覆盖了绝大多数场景实际排查时先对号入座缩小范围再深入看代码效率比盲猜高得多。5.2 几个印象深刻的坑第一个坑是消息被覆盖。有一次排查一个偶发失败日志里异常消息是标准的请求参数校验失败看起来很正常但用户反馈的场景跟参数校验根本没关系。后来发现是统一异常处理器里有个兜底分支把所有未识别的异常都重新包装成了校验失败。这种善意的兜底反而抹掉了真实信息后来我们把兜底逻辑改成保留原始异常并单独打一条告警日志问题才水落石出。第二个坑是日志级别写错。有个模块的错误日志用的是 info 级别而线上环境只输出 warn 以上结果就是代码里明明有日志线上就是看不到。这类问题排查起来特别费劲因为代码看着完全正确。后来我们在代码规范里明确要求所有 catch 块内的异常记录一律用 error 级别需要额外上下文再用 warn 补充从制度上避免这个问题。第三个坑是空字符串陷阱。有个接口的错误提示偶尔显示为空白查了半天发现是构造异常时传了一个变量那个变量在某些分支下是空字符串而不是 null。空字符串通过了很多判空检查最后拼到界面上就是一片空白。从那以后我们在展示层统一加了去空白处理空白一律替换成默认提示。第四个坑跟性能有关。有个高频接口为了信息完整在异常里拼了很长的上下文包括整个请求体。结果异常一多日志量暴涨磁盘三天就满了。这件事让我意识到异常信息不是越多越好关键信息加上唯一标识就够了详细的请求内容应该通过标识去日志平台检索而不是塞进异常里。回到最开始那个问题e.getMessage() 拿不到东西本质上不是 API 的问题而是信息在传递链路的某一环被丢掉了。找到那一环问题就解决了一大半。我现在的习惯是任何新写的 catch 块先把异常对象完整记一笔再谈其他处理这个动作坚持几年下来省掉的排查时间远超当初多敲的那几个字符。
e.getMessage() 打出来是 null日志里只剩孤零零一行java.lang.NullPointerException或者干脆就是个空格子这是我在无数技术讨论里见得最多的一类求助。程序明明抛了异常catch 也进去了偏偏拿不到一句人话排查起来就像在黑屋子里找开关。这篇文章就围绕 e.getMessage() 拿不到错误信息这件事往下拆从 Throwable 内部的存储结构到异常被包装、被框架翻译、被日志框架吞掉、被线程池藏起来、被 JIT 优化抹平这五种典型路径再到一套可以直接抄走的排查流程和工具方法。不管你是刚写第一个 try-catch 的新手还是天天在线上捞日志的老手这里面的坑大概率你都踩过至少两个。1. 先把地基打牢e.getMessage() 里的那段字符串到底是什么1.1 Throwable 内部其实只存了一个 detailMessage 字段很多人下意识觉得异常对象是个信息很丰富的东西里面应该有错误码、错误描述、发生位置、上下文参数。实际上翻开 JDK 源码你会发现Throwable 里跟描述相关的成员少得可怜核心就是一个private String detailMessage外加一个cause指向上一层异常再加一个StackTraceElement[]数组记录调用栈。getMessage()做的事情简单到令人失望——原样返回那个detailMessage字段字段是 null 就返回 null不做任何兜底、不做任何加工、不会去猜你想要什么。这就意味着一个残酷的事实异常信息里有没有内容完全取决于这个异常对象在被 new 出来的那一刻有没有人给它传字符串。传了就有没传就是 null后面任何地方都变不出来。所以当你看到 e.getMessage() 为 null第一反应不应该是日志框架坏了而应该是这个异常在构造时就没带消息。理解了这一点很多困惑会瞬间打通。比如为什么空指针异常经常没有消息为什么某些工具类抛出的异常只有类名没有描述为什么同一个接口有时候有提示有时候没有——因为这些异常来源不同有的走的是带参构造有的走的是无参构造中间没有任何统一保证。1.2 getMessage、toString、printStackTrace 三者的取舍既然 detailMessage 可能为 null那为什么有些地方打印出来的异常看起来又有信息了因为toString()做了兜底。它的逻辑大致是取类名再拼上getLocalizedMessage()的返回值如果消息是 null 就只返回类名。所以你打e.toString()或者直接把异常对象拼进字符串至少能看到java.lang.IllegalStateException这样的类型信息比一个 null 强得多。printStackTrace()则是另一条路它把异常类型、消息、完整调用栈一起写到标准错误流格式是人类可读的多行文本。这三者的定位完全不同getMessage()适合给用户看的简短提示toString()适合拼在单行日志里做粗筛printStackTrace()适合本地调试看完整链路。我在做代码评审时经常看到有人用log.error(e.getMessage())这一行日志在生产环境基本等于没打——既没有异常类型也没有堆栈连是哪个类抛的都看不出来。还有一个容易被忽略的成员是getLocalizedMessage()它默认直接调用getMessage()只有自定义异常重写了这个方法才会有差异。如果你的项目里有国际化需求重写它是有意义的如果没有把它和 getMessage() 混用没有实际收益反而会让排查的人多绕一圈。顺带提一句getMessage()返回空字符串和返回 null 是两回事。前者说明构造时传了个空串后者说明压根没传。日志里两者看起来都像没内容但排查方向不完全一样判断时最好用判空工具一起处理而不是简单写if (msg null)。2. 六种典型场景为什么你手里的 message 是空的2.1 异常对象从出生起就没带消息最常见的一类就是异常在创建时走的是无参构造。业务代码里写throw new RuntimeException()、throw new IllegalStateException()、throw new UnsupportedOperationException()的地方非常多尤其是在这个分支理论上不会进来的防御性代码里作者往往图省事不写描述。这类异常一旦真的抛出getMessage()必然返回 null你在上层怎么折腾都拿不到东西。JDK 自己抛的异常也有类似情况。空指针异常在较新的 JDK 版本里会附带一句哪个变量为 null的详细描述但这个能力需要显式开启对应的虚拟机参数早期版本默认是不带的抛出来就是光秃秃一个类名。数组越界、算术异常在正常路径下一般有描述但在被 JIT 优化过之后又会变回裸异常这个后面单独说。还有一种隐蔽情况自定义异常继承了 RuntimeException但只写了带参构造父类构造里没有调用super(message)而是自己存了一个字段。结果getMessage()走的是父类的实现返回 null而你以为信息存在自己的字段里。这种 bug 我在接手别人代码时遇到过两次表现就是明明传了错误描述打出来却是 null对着源码看半天才发现构造函数少了一行。提示判断一个异常是否天生没消息最快的办法是看抛出点的源码。如果那个位置是第三方 jar 里的代码用反编译工具看一眼构造函数调用即可几秒钟的事。2.2 包装时把 cause 丢了第二类是高发区几乎每个项目都有一两处。典型写法是这样的try { doSomething(); } catch (Exception e) { throw new BizException(操作失败); }这段代码把原始异常吞掉了只留下一个自己编的字符串。等这个异常冒到最外层getMessage()返回的是操作失败看起来有内容但对排查毫无帮助——你不知道底层到底是数据库超时、参数非法还是空指针。更糟的情况是连字符串都不写直接throw new BizException()那就真的什么都没有了。正确的写法是把原始异常作为 cause 传进去try { doSomething(); } catch (Exception e) { throw new BizException(操作失败, e); }这样异常链就完整了外层 message 给人看内层 cause 给排查用。判断标准很简单任何一个 catch 块里重新抛出的异常都必须带上原异常引用。我在团队里推行这条规矩时直接在代码检查工具里加了一条规则catch 块内 new 异常但没传 cause 的直接报错效果立竿见影。与之配套的认知是getMessage()永远只返回当前这一层的信息。想看全貌必须顺着getCause()往下走一层层剥直到 cause 为 null。很多人拿不到有用信息不是信息不存在而是只看了一层就放弃了。2.3 框架层的二次翻译如果你用的是带持久层的容器框架会发现数据库原始异常很少能直接冒到业务层中间会被翻译成框架自己的一套异常体系。翻译之后的异常 message 通常是一句很长的英文比如某条语句执行失败真正的数据库错误码、约束名、字段名都藏在 cause 里有时候要往下剥三四层才能看到。反射调用也是重灾区。用Method.invoke()调用目标方法如果目标方法内部抛了异常反射层会把它包成一个InvocationTargetException而这个包装异常的getMessage()往往是 null。真正的异常要用getTargetException()或者getCause()取。我见过有同学在反射调用外面写catch (Exception e) { log.error(e.getMessage()); }日志里一片空白然后怀疑人生地查了两个小时。部分容器框架提供了便捷方法比如取最具体原因的 API能一步跳到异常链末端。这个思路值得借鉴——与其每次手写循环不如在项目里封一个公共方法所有需要展示错误的地方统一调用。2.4 日志侧根本没把 message 写出去到这一步就要怀疑日志本身了。常见的三种写法问题第一种log.error(e.getMessage())。这一行只输出了一个字符串异常对象的类型和堆栈全丢了如果 message 恰好是 null日志框架会打出一个null或者干脆什么都不打。第二种占位符和参数对不上。log.error(处理失败 {}, e)这种写法如果占位符只有一个而参数传了异常对象有些实现会把它当成普通参数做字符串拼接走toString()堆栈就没了。正确姿势是log.error(处理失败, e)异常对象放在最后一个参数位置且不带占位符日志实现会识别出来并打印完整堆栈。第三种配置问题。日志级别设成了 ERROR 但你的代码用的是log.info或者 appender 没配、异步队列满了丢日志、日志文件被切割覆盖。这类问题的特征是偶发同一段代码有时候有日志有时候没有排查时要先确认日志是否真的写到了磁盘而不是停留在内存缓冲区里。我个人的习惯是任何 catch 块里的错误日志第一个参数写固定前缀加关键业务标识第二个参数直接传异常对象绝不在日志语句里调用getMessage()。这样无论 message 是 null 还是有内容堆栈永远都在。2.5 异步链路把异常藏进了 Future用线程池执行任务时如果提交方式是submit()任务内部抛出的异常会被封装进Future不会触发线程的未捕获异常处理器也不会打印任何日志。只有当有人调用future.get()时才会抛出一个包装异常真正的原因在它的 cause 里。如果你提交完就不管了异常就永远静静地躺在那里。execute()的行为不同异常会向上冒到线程的未捕获异常处理器默认会打印到标准错误流但这依赖于你配置了处理器否则可能被静默丢弃。异步编排工具也有类似特性join()和get()抛出的包装类型不一样剥壳的层数也不一样。我一般会在异步任务的入口包一层统一的捕获逻辑把异常完整记录下来再往外抛避免依赖调用方是否记得取值。这件事看起来琐碎但在排查任务跑了但没结果这类问题时能省下大量时间。注意异步场景下getMessage()拿到的往往是包装异常的 message真正的错误描述在 cause 链里。看到包装类型的异常名第一反应就应该是往下一层找。2.6 JIT 优化后的裸异常这一类最反直觉也是很多老手都会愣一下的场景同样的代码、同样的位置前几百次报错日志里堆栈齐全、消息完整某一天之后突然变成一行没有堆栈、没有消息的异常类名重启服务后又恢复正常。原因是虚拟机有一个默认开启的优化参数含义是在快速抛出模式下省略堆栈。当某个位置反复抛出同一类由虚拟机隐式产生的异常空指针、数组越界、算术异常、类型转换异常等并且这段代码已经被即时编译器编译成优化版本虚拟机会认为这个异常太常见了每次都采集堆栈太浪费性能于是改用一个预先分配好的、没有堆栈、没有消息的异常实例直接抛出。这个优化的收益是真的——异常构造里最贵的一步就是填充堆栈高频抛异常的场景下开销非常可观。但代价是排查信息全部丢失。解决办法有两个一是在启动参数里关掉这个优化加上对应的关闭开关适合排查阶段临时使用二是别盯着最新那条日志看往前翻找到第一次出现的那一条那时候堆栈还是完整的。需要强调的是这个优化只影响虚拟机自己抛出的隐式异常代码里throw new XxxException(...)显式创建的不受影响。所以如果你看到 message 为 null 且异常类型是空指针又恰好符合高频重复的特征基本可以锁定是这个问题。3. 实操排查从一行日志挖到根因3.1 第一步分清是 null 还是没打出来拿到没有错误信息这个现象先别急着改代码花两分钟做个区分。做法是把那行日志改成同时输出三样东西异常类名、getMessage()的原始返回值、以及完整堆栈。如果类名和堆栈都有只有 message 是 null那就是 2.1 或 2.2 的问题如果连堆栈都没有那大概率是 2.4 的日志写法问题或者 2.6 的优化问题如果堆栈里出现了一个包装类型的异常那就是 2.3 或 2.5。这个区分动作看起来多余实际上能省掉大量无效尝试。我见过有人一上来就怀疑日志框架折腾了半天配置文件最后发现是代码里throw new RuntimeException()没写消息跟日志一毛钱关系没有。区分清楚之后把范围缩小到具体的某一层再往下钻就快多了。3.2 第二步写一个能挖穿异常链的工具方法与其在每个 catch 块里手写循环不如一次性封一个方法项目里所有需要展示错误的地方都调它。核心逻辑是顺着 cause 往下走同时做好三件事防自引用死循环、限制最大深度、把每一层的类名和消息都拼出来。public final class ExceptionUtils { private static final int MAX_DEPTH 20; public static String dump(Throwable root) { if (root null) { return null; } StringBuilder sb new StringBuilder(256); SetThrowable seen Collections.newSetFromMap(new IdentityHashMap()); Throwable cur root; int depth 0; while (cur ! null depth MAX_DEPTH) { if (!seen.add(cur)) { sb.append( (检测到循环引用停止)); break; } sb.append([).append(depth).append(] ) .append(cur.getClass().getName()) .append(: ); String msg cur.getMessage(); sb.append(msg null ? (message 为 null) : msg) .append(System.lineSeparator()); cur cur.getCause(); depth; } return sb.toString(); } }几个细节值得说明。用IdentityHashMap而不是HashSet是因为异常对象没有重写equals用普通集合虽然也能工作但语义上应该按对象身份判断避免某些重写了 equals 的自定义异常造成误判。限制最大深度是为了防止异常链异常长导致日志爆炸二十层在绝大多数场景下绰绰有余。把 null 显式标注成 (message 为 null) 而不是留空是为了让看日志的人一眼分辨没消息和消息是空串。这个工具方法我建议放在项目的公共基础模块里命名统一所有业务模块依赖它。团队里推广之后最直观的变化是排查问题时不再需要让人重新发版加日志现有日志里就能看到完整链路。3.3 第三步反射与 RPC 场景的兜底反射调用的地方catch 块要专门处理InvocationTargetException取出目标异常再走上面的工具方法。如果目标异常本身又是包装的工具方法会自动往下剥不用额外操心。跨进程调用的情况更麻烦一些。异常信息在经过序列化传输后通常只保留类名和消息堆栈会丢失某些实现下消息字段为空还会被序列化成 null。这时候接收端拿到的异常看起来什么信息都没有但发送端的日志里其实是完整的。排查这类问题时一定要两边日志对着看先确认发送端有没有把异常信息组装好再看接收端有没有正确反序列化。还有一个细节部分框架在异常消息为空时会用默认文案填充导致你以为拿到了真实信息实际上是框架编的。判断方法是看这条消息是否在所有同类错误里都一模一样如果是那基本就是框架兜底的文案不是真实原因。3.4 第四步日志侧的四项自检排查到最后把日志配置过一遍重点看四件事。第一错误日志的写法是否符合规范异常对象是否作为最后一个参数传入且不带占位符。第二日志级别是否匹配确认那条语句在线上环境真的会输出。第三appender 配置是否完整有没有因为异步队列容量不足而丢弃日志的情况这一点在流量高峰期特别容易出现。第四日志文件是否被正确滚动和保留有没有出现当天的日志文件里查不到问题这种尴尬。这四项过一遍大概五分钟但能排掉相当一部分日志里什么都没有的假象。我自己就遇到过一次排查了半天代码最后发现是异步日志队列满了开始丢弃把队列容量调大之后问题自动消失。4. 从源头堵住编码阶段的几条硬规矩4.1 自定义异常的最小正确写法自定义异常看着简单写错的概率却不低。我总结的最小正确形态包含三部分继承合适的父类、提供带消息和带 cause 的构造、把消息原样交给父类。public class BizException extends RuntimeException { private final String code; public BizException(String code, String message) { super(message); this.code code; } public BizException(String code, String message, Throwable cause) { super(message, cause); this.code code; } public String getCode() { return code; } }关键在于super(message)和super(message, cause)这两行。少了它们消息就存不进父类的字段getMessage()自然是 null。有些同学喜欢自己定义一个msg字段然后重写getMessage()返回它这也行得通但多了一层间接容易被后来的维护者忽略不如直接交给父类省事。另外提醒一句自定义异常不要重写fillInStackTrace()除非你非常确定性能是瓶颈。有些文章教人为了性能把它改成空实现结果堆栈全没了排查时哭都来不及。真要优化也应该只在明确测量过开销、且该异常用于流程控制的场景下才考虑。4.2 统一异常出口的包装规范一个成熟的业务系统异常最终都会汇聚到一个统一出口由它决定返回给调用方什么、记录什么日志。这个出口的包装逻辑决定了你后续能不能拿到有效信息。我的做法是分三层最内层保留原始异常不动中间层按业务语义包装并带上 cause最外层负责记录完整链路和转换对外响应。包装时消息要写清楚在做什么事的时候失败了而不是笼统的系统错误。比如生成订单快照失败就比操作失败有用得多至少能定位到模块。对外响应里不要直接暴露原始异常消息尤其是数据库相关的既有安全风险也不友好。正确做法是把异常码和一段面向用户的提示返回出去完整的异常链只写进日志。这两条信息通道分开是很多团队踩过坑之后才建立的规范。4.3 提示语与错误码的分层设计消息内容本身也值得设计。我一般把消息分成两类给用户看的和给开发看的。给用户看的要短、要可行动比如手机号格式不正确给开发看的要包含定位信息比如用户注册校验失败字段 phone值长度 13期望 11。这两类信息可以同时存在于异常链的不同层外层是用户提示内层是技术细节。展示时按场景各取所需日志里全量输出接口响应里只取外层。还有一个实践是给每类异常配一个稳定的错误码。有了错误码即使消息因为各种原因丢失也能通过码值反查原因。这在跨团队协作时尤其有用——对方只需要报一个码你就能定位到具体的分支逻辑不用猜。5. 常见问题速查与踩坑记录5.1 一页速查表现象最可能原因快速验证方式处理方向message 为 null堆栈完整异常是空指针异常构造时未传消息看抛出点源码是否用无参构造补消息或改用带参构造message 有内容但是笼统的操作失败catch 后重新抛异常未带 cause搜索 catch 块里的 new 语句补上 cause 参数日志里只有一行类名没有堆栈日志语句只传了 getMessage()检查日志写法异常对象作为最后一个参数传入堆栈里有 InvocationTargetException反射调用包装看异常类型名取 getTargetException 后再处理前几次有堆栈后面突然没有虚拟机快速抛出优化往前翻最早的报错记录排查期关闭优化或看早期日志异步任务失败但无任何日志用了 submit 且未取结果检查提交方式换成 execute 或在任务内捕获跨进程调用后消息为空序列化时丢失对比两端日志两端都记录完整异常链日志偶发缺失高峰期更明显异步 appender 队列满丢弃查看日志框架内部状态调大队列或改同步输出这张表覆盖了绝大多数场景实际排查时先对号入座缩小范围再深入看代码效率比盲猜高得多。5.2 几个印象深刻的坑第一个坑是消息被覆盖。有一次排查一个偶发失败日志里异常消息是标准的请求参数校验失败看起来很正常但用户反馈的场景跟参数校验根本没关系。后来发现是统一异常处理器里有个兜底分支把所有未识别的异常都重新包装成了校验失败。这种善意的兜底反而抹掉了真实信息后来我们把兜底逻辑改成保留原始异常并单独打一条告警日志问题才水落石出。第二个坑是日志级别写错。有个模块的错误日志用的是 info 级别而线上环境只输出 warn 以上结果就是代码里明明有日志线上就是看不到。这类问题排查起来特别费劲因为代码看着完全正确。后来我们在代码规范里明确要求所有 catch 块内的异常记录一律用 error 级别需要额外上下文再用 warn 补充从制度上避免这个问题。第三个坑是空字符串陷阱。有个接口的错误提示偶尔显示为空白查了半天发现是构造异常时传了一个变量那个变量在某些分支下是空字符串而不是 null。空字符串通过了很多判空检查最后拼到界面上就是一片空白。从那以后我们在展示层统一加了去空白处理空白一律替换成默认提示。第四个坑跟性能有关。有个高频接口为了信息完整在异常里拼了很长的上下文包括整个请求体。结果异常一多日志量暴涨磁盘三天就满了。这件事让我意识到异常信息不是越多越好关键信息加上唯一标识就够了详细的请求内容应该通过标识去日志平台检索而不是塞进异常里。回到最开始那个问题e.getMessage() 拿不到东西本质上不是 API 的问题而是信息在传递链路的某一环被丢掉了。找到那一环问题就解决了一大半。我现在的习惯是任何新写的 catch 块先把异常对象完整记一笔再谈其他处理这个动作坚持几年下来省掉的排查时间远超当初多敲的那几个字符。
核心思想与竞赛应用解析)
