异常链的核心作用是确保错误根源可追溯,必须通过Throwable带cause构造方法构建、日志中递归打印getCause()、自定义异常显式委托cause参数,任一环节缺失都会导致根因丢失。
异常链的核心作用是:让“谁导致了这个错误”可追溯,而不是只看到最后一层抛出的异常。 它不是锦上添花的功能,而是你在排查生产环境 NPE、SQL 异常、Feign 调用失败时,能否 3 分钟内定位到数据库连接池耗尽还是配置写错了的关键。
cause 是最常用也最安全的方式Java 所有异常类(Exception、RuntimeException 等)都继承自 Throwable,而它提供了带 cause 参数的构造方法——这是构建异常链的「黄金路径」。
new XxxException("业务失败", originalException),比如:throw new ServiceException("订单创建失败", e);initCause() 后置设置——它只能调用一次,且若异常已初始化过(如被序列化或打印过堆栈),会直接抛 IllegalStateException;NullPointerException 或 IllegalArgumentException 这类运行时异常,且你包装成新的 RuntimeException,链依然有效;但若包装成受检异常(如 IOException),需确保方法签名 throws 正确类型;try-with-resou
rces 自动添加 suppressed 异常(非 cause),别把它和 cause 混为一谈——getCause() 只返回一个,getSuppressed() 返回数组。getCause() 就等于白建异常链很多团队写了包装异常,却在日志里只调 e.toString() 或 e.getMessage(),结果日志里永远只有“服务调用失败”,看不到底层是 ConnectException: Connection refused。
logger.error("xxx", e) 会自动递归打印整个 cause 链(包括 nested exception),这是最省心的用法;e.printStackTrace(new PrintWriter(stringWriter)) 或调用 e.getStackTrace() + e.getCause() 循环展开;ErrorController 或全局 @ExceptionHandler,返回 JSON 时容易只序列化顶层异常——记得显式加 e.getCause() != null ? e.getCause().getMessage() : null 字段。cause 构造方法很多人写自定义异常时只重载了 String message 构造方法,忘了把 Throwable cause 也接住,结果链在第一层就断了。
public class BizException extends RuntimeException {
public BizException(String message) {
super(message);
}
// ❌ 缺少这个构造方法 → 包装时 cause 丢失
public BizException(String message, Throwable cause) {
super(message, cause); // ✅ 必须显式调用父类带 cause 的构造器
}
}
@AllArgsConstructor,它不会自动识别 Throwable 为 cause 参数,仍需手写或改用 @SuperBuilder + 显式构造;ResponseStatusException 支持 cause,但它的子类(如 HttpRequestMethodNotSupportedException)不一定透传,谨慎包装。真正难的不是写对那行 new XxxException(msg, e),而是整条调用链上每个中间层都保持这个习惯——漏一层,根源就沉底。线上查问题时,最痛的不是没日志,而是日志里只有一半链。