为什么异常链传递能帮你少掉头发？——从一次线上事故说起
先跟你复盘下我朋友那个线上事故的经过。他们的支付系统有个“创建订单”接口，某天突然出现1%的失败率，日志里打印的是：java.lang.RuntimeException: 创建订单失败。就这么一句话，没有更多信息。他们团队一开始怀疑是参数问题，查了请求日志，所有参数都正常；又怀疑是缓存问题，清了缓存也没用；最后没办法，只能把代码从controller到service到dao一层一层看。
看到service层时发现这么一段代码：
public Order createOrder(OrderDTO dto) {
try {
return orderDao.insert(dto); // 调用DAO层插入数据库
} catch (SQLException e) {
// 捕获SQL异常，抛出自定义业务异常
throw new RuntimeException("创建订单失败");
}
}
问题就在这里！DAO层抛出的SQLException被捕获后，他们直接new了个RuntimeException抛出去，但没有把原始的SQLException传进去。结果就是原始异常的堆栈信息、错误码这些关键信息全丢了，日志里自然看不到数据库连接超时的具体原因。后来他们改成throw new RuntimeException("创建订单失败", e)，重新部署后，日志里立刻显示了完整的异常链：
java.lang.RuntimeException: 创建订单失败
at com.example.service.OrderService.createOrder(OrderService.java:23)
Caused by: java.sql.SQLException: 数据库连接超时 (连接池已满)
at com.example.dao.OrderDao.insert(OrderDao.java:15)
... 5 more
看到“连接池已满”，他们马上扩容了数据库连接池，问题半小时就解决了。你看，就差一个参数，排查时间从3天缩短到半小时，这就是异常链传递的威力。
那异常链到底是什么？其实很简单，Java里所有异常都继承自Throwable类，而Throwable有个cause字段，专门用来存储“引发当前异常的原始异常”。当你打印异常堆栈时（比如调用printStackTrace()），JVM会顺着这个cause字段一层层往下找，把所有关联的异常都打印出来，形成一条完整的“异常链”。就像警察破案时顺着线索找源头，异常链就是程序报错时的“线索链”，少了一环，就可能断案无门。
Java官方文档里其实早就强调过这点：“如果一个异常是由另一个异常引起的，应该保留原始异常的引用，以便后续排查问题”（引用自Java官方文档-Throwable类{:target=”_blank” rel=”nofollow”}）。可惜很多人写代码时图省事，或者根本不知道这个细节，导致异常链断裂，日志信息残缺。
90%的人都在踩的3个坑，以及如何正确传递异常链
知道了异常链的重要性，接下来就跟你聊聊实际开发中最容易踩的几个坑，以及怎么避开它们。这些坑我自己刚工作时也踩过，带团队后发现新人几乎都会犯，你可以对照着看看自己有没有中招。
坑1：捕获异常后直接抛新异常，原始cause“人间蒸发”
这是最常见的坑，就像前面说的订单系统案例。很多人捕获异常后，觉得“我已经知道这里会出错了，抛个新异常提示业务人员就行”，结果把原始异常丢了。比如这样的代码：
try {
// 调用第三方API获取用户信息
userInfo = userApi.getUser(userId);
} catch (IOException e) {
// 错误做法：直接抛新异常，没带原始cause
throw new RuntimeException("获取用户信息失败");
}
这种情况下，IOException的具体原因（比如“连接超时”“API返回404”）都会丢失。线上日志只会显示“获取用户信息失败”，你根本不知道是网络问题还是第三方API本身的问题。
正确做法
：抛新异常时，把原始异常作为cause传进去。Java的所有异常类（包括自定义异常）都提供了带Throwable cause参数的构造方法，直接用就行：
try {
userInfo = userApi.getUser(userId);
} catch (IOException e) {
// 正确做法：传递原始cause
throw new RuntimeException("获取用户信息失败", e);
}
这样日志里就会同时显示外层异常和原始异常，一眼就能看到“哦，原来是第三方API返回了503错误”。
坑2：用printStackTrace代替异常传递，日志“断层”
还有一种常见错误：捕获异常后，觉得“我打印一下堆栈，再抛个新异常就行”，结果日志里虽然有原始异常，但和外层异常对不上，形成“日志断层”。比如：
try {
// 解析JSON字符串
data = JSON.parseObject(jsonStr, Data.class);
} catch (JSONException e) {
// 错误做法：先打印原始异常，再抛新异常（不带cause）
e.printStackTrace(); // 打印原始异常到控制台
throw new RuntimeException("解析数据失败");
}
你可能觉得“我都打印e的堆栈了，还怕找不到原因？”但实际线上环境中，printStackTrace()的输出可能不会被日志框架（比如Logback、Log4j）捕获，而是直接打印到控制台，甚至被忽略。就算被捕获了，原始异常的日志和外层异常的日志可能不在同一个地方（比如时间戳差几秒，或者被其他日志刷屏），排查时你根本不知道这两个异常是同一个请求触发的。
更糟的是，如果中间有多层调用，每一层都这么做，日志里会堆满零散的异常堆栈，你根本分不清哪个是哪个的cause。
正确做法
：永远不要用printStackTrace()代替异常传递，而是通过cause参数把原始异常“链”起来。如果需要打印日志，可以用日志框架（比如log.error("解析数据失败", e)），但同时一定要把原始异常传给新异常：
try {
data = JSON.parseObject(jsonStr, Data.class);
} catch (JSONException e) {
// 正确做法：用日志框架打印，同时传递cause
log.error("解析数据失败", e); // 日志框架会记录完整堆栈
throw new RuntimeException("解析数据失败", e); // 传递原始异常
}
这样日志框架会把异常链完整记录下来，而且外层异常和原始异常会关联在一起，排查时一目了然。
坑3：自定义异常没留构造方法，想传cause都传不了
很多项目会定义自己的业务异常，比如BusinessException，但如果自定义异常没提供带cause的构造方法，你想传递原始异常都传不了。比如：
// 错误示例：自定义异常只提供了message参数的构造方法
public class BusinessException extends Exception {
public BusinessException(String message) {
super(message); // 只调用了父类的message构造方法
}
}
// 使用时想传cause，结果编译报错
try {
// ...
} catch (SQLException e) {
// 编译错误：BusinessException没有带Throwable的构造方法
throw new BusinessException("业务异常", e);
}
这时候你要么放弃传递cause（又掉回第一个坑），要么只能手动调用initCause()方法，但这样代码更繁琐，还容易忘。
正确做法
：自定义异常时，一定要提供带message和cause的构造方法，直接调用父类的对应构造方法就行：
// 正确示例：提供带cause的构造方法
public class BusinessException extends Exception {
// 带message的构造方法
public BusinessException(String message) {
super(message);
}
// 带message和cause的构造方法（重点）
public BusinessException(String message, Throwable cause) {
super(message, cause); // 调用父类的message+cause构造方法
}
}
// 使用时就能正常传递cause了
try {
// ...
} catch (SQLException e) {
throw new BusinessException("业务异常", e); // 现在不报错了
}
这样不管是业务异常还是系统异常，都能把原始cause传下去，异常链就不会断。
正确传递异常链的2种方式（附代码模板）
聊了这么多坑，最后 一下正确传递异常链的两种方式，你可以直接记下来当模板用：
方式1：用构造方法传递cause（推荐）
这是最简洁的方式，直接在new异常时传入原始cause，适用于大部分场景：
try {
// 可能抛出异常的代码
} catch (SomeException e) {
// 直接用带cause的构造方法
throw new NewException("异常描述", e);
}
方式2：用initCause()方法传递cause（特殊场景）
如果异常类没有提供带cause的构造方法（比如某些第三方库的异常），可以用initCause()方法手动关联cause：
try {
// ...
} catch (ThirdPartyException e) {
// 先new一个异常，再调用initCause关联cause
NewException ex = new NewException("异常描述");
ex.initCause(e); // 手动设置原始异常
throw ex;
}
不过要注意，initCause()只能调用一次，重复调用会抛IllegalStateException，所以尽量还是用构造方法。
最后给你一个小技巧：以后写异常处理代码时，养成一个习惯——每次throw new 异常()时，先看看括号里有没有cause参数。如果有原始异常，就加上；如果没有，再想想“这里真的没有原始异常吗？是不是我漏捕获了？” 这个小习惯能帮你避开90%的异常链问题。
你平时写代码时有没有遇到过异常链断裂的情况？或者有什么处理异常的小技巧？欢迎在评论区分享，咱们一起避坑～
说到自定义异常，我发现很多人刚开始写的时候都容易忽略一个点——就是没给异常加个能传原始异常的构造方法。我之前带过一个实习生，他定义了个BusinessException，里面就一个带message的构造方法，结果用的时候麻烦了：捕获到SQL异常想转成业务异常，发现根本传不了原始异常，最后只能眼睁睁看着异常链断了，日志里啥关键信息都没有。后来我跟他说，其实解决办法特简单，你给自定义异常加个“带原始异常”的构造方法就行，就像给异常开了个“后门”，让原始异常能顺着这个门传下去。
具体怎么写呢？你定义异常类的时候，除了那个常用的public BusinessException(String message) { super(message); }，一定得再加一个构造方法，参数是String message和Throwable cause，然后在方法里调用super(message, cause)。就像这样：public BusinessException(String message, Throwable cause) { super(message, cause); }。这个super调用特别关键，相当于告诉父类“这是引发我的原始异常，你帮我存好”。之后用的时候就方便了，比如catch到SQLException e，直接throw new BusinessException("创建订单失败", e)，原始异常e就通过这个构造方法传进去了。这样异常链就不会断，日志里就能看到从自定义异常到原始异常的完整链条，排查问题的时候一眼就能看到底，比之前瞎猜可省事儿多了。
什么是Java异常链传递机制？
简单说，异常链传递机制就是让多个异常通过“因果关系”关联起来的机制。Java里所有异常都有个cause字段，专门存“引发当前异常的原始异常”。当你抛新异常时带上原始异常，打印日志时就会显示“外层异常 -> 原始异常”的链条，像破案时顺着线索找源头，帮你快速定位问题根本原因。
为什么必须传递原始异常，只抛新异常不行吗？
不行。原始异常里藏着关键信息：比如SQLException会告诉你数据库错误码、IOException会显示网络超时原因、NullPointerException会指出具体哪行代码空指针。如果只抛新异常（比如new RuntimeException(“操作失败”)），原始异常的堆栈、错误码这些“破案线索”就全丢了。就像文章里的例子，没传原始异常时查了3天，传了之后半小时解决——这就是差别。
自定义异常怎么正确传递原始异常？
核心是给自定义异常加个“带原始异常”的构造方法。比如定义BusinessException时，除了带message的构造方法，一定要加个带message和cause的构造方法，直接调用父类的super(message, cause)：
public class BusinessException extends Exception {
// 带message的构造方法
public BusinessException(String message) {
super(message);
}
// 带message和原始异常的构造方法（重点）
public BusinessException(String message, Throwable cause) {
super(message, cause); // 把原始异常传给父类
}
}
这样用的时候就能直接throw new BusinessException(“业务失败”, 原始异常)，异常链就不会断了。
异常链传递会不会让日志变得冗余？
不会，反而会让日志更清晰。日志框架（比如Logback、Log4j）打印异常时，会自动用Caused by:区分原始异常，像这样：
java.lang.RuntimeException: 创建订单失败 // 外层异常
at com.example.service.OrderService.createOrder(OrderService.java:23)
Caused by: java.sql.SQLException: 数据库连接超时 // 原始异常
at com.example.dao.OrderDao.insert(OrderDao.java:15)
你看，关键信息一目了然，完全不冗余。反而是不传递原始异常，日志里只有一句“操作失败”，才会让你猜来猜去更浪费时间。
如果已经忘记传递原始异常，有什么临时补救办法？
如果代码已经上线，来不及改构造方法传递cause，可以临时在catch块里用日志框架打印原始异常，比如：
catch (SQLException e) {
// 临时补救：用日志打印原始异常（别用printStackTrace！）
log.error(“创建订单时数据库出错”, e); // 日志框架会记录完整堆栈
throw new RuntimeException(“创建订单失败”); // 后续修复时记得加e参数
}
这样日志里至少能看到原始异常信息，帮你临时定位问题。但这只是权宜之计，最终还是要按文章里说的，通过构造方法传递cause，才能彻底解决问题。
