异常链传递的基础：从原理到实现
你可能会说：“不就是抛异常吗？try-catch后throw new XXException不就行了？” 这话没错，但如果只是简单抛新异常，就像你把快递盒上的原始面单撕掉，重新贴了个空白面单——快递员（也就是排查问题的你）根本不知道这包裹最初从哪来、里面装了啥。异常链传递的核心，就是保留这个“原始面单”，让每个异常都知道自己的“上一级异常”是谁，形成一条完整的因果链。
到底什么是异常链？
简单说，异常链就是多个异常通过“因果关系”串联起来的结构：底层异常（比如数据库连接失败）是“因”，被上层异常（比如订单创建失败）包裹作为“果”，上层异常又可能被更上层的异常包裹，最终传递到顶层。这样无论在哪一层捕获异常，都能通过getCause()一路追溯到最原始的错误。
我举个自己经历的例子：前年做一个物流系统时，仓库管理模块突然频繁报“库存更新失败”，但日志里只有业务异常信息，没有具体原因。后来翻代码才发现，DAO层用了catch (SQLException e) { throw new BusinessException("库存更新失败"); }——这里的SQLException就是原始“因”，但被直接丢掉了，导致我们以为是业务逻辑问题，实际上是数据库索引失效导致的查询超时。后来改成throw new BusinessException("库存更新失败", e)（用带cause的构造方法），下次再出问题时，通过e.getCause()直接看到了SQLTimeoutException，5分钟就定位到了索引问题。这就是异常链的价值：它不是让异常变复杂，而是让异常“说真话”。
实现异常链的两种核心方式
Oracle官方文档里明确提到，Java异常链的实现有两种标准方式（你可以看Oracle官方异常处理指南），这两种方式你得记牢，别用野路子：
第一种是通过initCause()方法。所有Throwable类都有这个方法，你可以在创建异常后，用它设置原始异常。比如：
try {
// 调用数据库方法，可能抛SQLException
} catch (SQLException e) {
BusinessException be = new BusinessException("订单查询失败");
be.initCause(e); // 把SQLException设为原始cause
throw be;
}
不过要注意，initCause()只能调用一次，重复调用会抛IllegalStateException——这就像你不能给一个人安两个“亲生父母”，异常的原始cause也只能有一个。
第二种更常用，直接用带cause参数的构造方法。大部分标准异常（比如RuntimeException、IOException）都提供了(String message, Throwable cause)的构造方法，业务异常也 你这么定义。比如上面的例子，直接写成throw new BusinessException("订单查询失败", e)更简洁，还能避免忘记调用initCause()的问题。我现在写业务异常类时，一定会加三个构造方法：无参、带message、带message和cause，就是为了方便传递异常链。
可能你会问：“那非受检异常和受检异常怎么选？” 我的 是：业务异常优先用非受检异常（继承RuntimeException），这样不用在方法签名上加throws，减少代码冗余；但如果是需要强制处理的异常（比如文件必须关闭），可以用受检异常。不过无论哪种，传递时都要带上原始cause——这一点不分受检与否。
分层场景下的传递策略：从DAO到Controller
异常链不是“一抛了之”，不同层级的职责不同，传递方式也得“因地制宜”。你想啊，DAO层面对的是数据库、缓存这些底层资源，Service层处理业务逻辑，Controller层对接前端——就像工厂流水线，每个环节的“质检标准”不一样，异常处理也得有对应的策略。
DAO层：把“技术异常”包装成“业务异常”
DAO层是最接近底层资源的地方，会遇到各种“技术异常”：SQLException（数据库连接失败）、RedisException（缓存超时）、IOException（文件读写错误）……这些异常对业务层来说太“底层”了，直接抛给Service层，业务开发同学可能看不懂“ORA-12170: TNS:连接超时”是什么意思。
这时候就需要“包装”：把技术异常转换成业务能理解的异常。比如DAO层查询用户订单时，数据库连接失败，你不能直接抛SQLException，而应该抛OrderQueryException（业务异常），并把SQLException作为cause传进去。我之前做支付系统时，就定义了PaymentDaoException，专门包装DAO层的技术异常，message写“支付记录查询失败”，cause保留原始的数据库异常——这样业务层一看就知道是支付模块的查询出了问题，而具体是数据库连接失败还是SQL语法错误，通过getCause()就能追溯。
错误做法
：直接抛技术异常，或者抛新异常时不保留cause。比如：
// 错误示例：直接抛技术异常，业务层无法理解
catch (SQLException e) {
throw e; // 直接抛SQLException，Service层一脸懵
}
// 错误示例：抛新异常但丢失cause，原始信息断层
catch (SQLException e) {
throw new RuntimeException("查询失败"); // 没有e，根因丢了
}
正确做法
：包装成业务异常，保留原始cause。比如：
// 正确示例：包装为业务异常，保留技术异常作为cause
catch (SQLException e) {
throw new OrderDaoException("订单DAO层查询异常", e);
}
这里的OrderDaoException应该继承RuntimeException（非受检），并在构造方法中接受cause参数。
Service层：传递时“补充上下文”，不“截断链条”
Service层是业务逻辑的核心，可能调用多个DAO，也可能调用其他Service。这一层的异常处理有两个原则：不吞异常、补充上下文。
先说“不吞异常”——这是我见过最多的坑！有些同学觉得“这个异常不重要，catch住不抛就行了”，结果线上出了问题，日志里啥都没有。去年有个项目就是这样：用户反馈“提交订单后看不到物流信息”，查日志发现Service层有个try-catch：
try {
logisticsService.createLogistics(orderId); // 调用物流服务创建物流单
} catch (Exception e) {
log.error("创建物流单失败"); // 只打日志，没抛异常！
}
结果物流服务其实是因为“订单ID格式错误”抛了异常，但被这里的catch吞了，导致订单创建成功但物流单没生成，用户看不到物流信息。这种“吞异常”的做法，比不处理异常还可怕——不处理至少会抛出来，吞了就彻底成了“暗箱操作”。
再说说“补充上下文”。有时候原始异常的信息不够，需要在传递时加上当前上下文。比如Service层调用DAO层查询订单，DAO层抛了OrderDaoException（cause是SQLException），Service层可以在抛出去时，补充订单ID、用户ID这些关键信息。我一般会这么做：
try {
orderDao.queryById(orderId);
} catch (OrderDaoException e) {
// 补充上下文：当前是哪个订单查询失败
throw new OrderServiceException("订单服务查询订单[" + orderId + "]失败", e);
}
这样日志里就会显示“订单服务查询订单[123456]失败”，结合cause里的SQLException，定位问题就快多了。
Controller层：统一“收口”，但别“一刀切”
Controller层作为前端的直接对接层，需要统一处理异常，避免把技术细节暴露给用户（比如不能让用户看到NullPointerException的堆栈信息）。但统一处理不代表“所有异常都返回500”，而是要根据异常类型返回不同的响应：业务异常返回具体错误码（比如“订单不存在”返回404），系统异常返回通用提示（比如“服务繁忙，请稍后再试”）。
这里推荐用Spring的@ControllerAdvice+@ExceptionHandler做全局异常处理。我之前项目的做法是：定义一个GlobalExceptionHandler，里面写不同异常的处理方法，比如处理OrderException返回订单相关错误，处理PaymentException返回支付相关错误，最后用Exception.class兜底处理未知异常。
关键是，在处理时要通过异常链追溯原始cause，记录完整日志。比如：
@ExceptionHandler(OrderServiceException.class)
public ResponseEntity handleOrderServiceException(OrderServiceException e) {
// 记录完整异常链日志，包括所有cause
log.error("订单服务异常: {}", e.getMessage(), e);
// 从业务异常中获取错误码，返回给前端
ApiError error = new ApiError(e.getErrorCode(), e.getMessage());
return new ResponseEntity(error, HttpStatus.BAD_REQUEST);
}
这里的log.error一定要传e（第三个参数），这样日志框架会自动打印完整的异常链，包括所有cause的堆栈信息——这是排查问题的“关键证据”。
避坑指南：这3个错误90%的人都犯过
最后给你 几个“高频踩坑点”，都是我和身边同事踩过的坑，你可以对照着避坑：
| 错误做法 | 为什么错 | 最佳实践 | |
|---|---|---|---|
| 吞异常（try-catch后不抛也不处理） | 根因丢失，排查无门 | 必须抛异常或记录完整日志（带堆栈），绝不吞异常 | |
| 抛新异常时不保留原始cause | 异常链断裂，无法追溯根因 | 用initCause()或带cause的构造方法，确保每个异常都有“上一级” |
|
| 过度包装（每层都包新异常） | 异常链过长，日志冗余，找根因要层层getCause() |
同一业务域内尽量用同一个异常类，只在跨域时包装（如DAO→Service） |
比如过度包装这个坑，我之前见过一个项目，DAO层抛DaoException，Service层包成ServiceException，Controller层包成ControllerException，最后日志里异常链有十几层，getCause().getCause().getCause()写了一长串——这完全是给自己找麻烦。记住：异常包装的目的是“传递信息”，不是“层数越多越好”。
下次你在处理支付回调异常时，可以试试这样：DAO层捕获SQLException后，包成PaymentDaoException（带cause）；Service层如果需要补充订单号，就包成PaymentServiceException（带cause和订单号）；Controller层用全局异常处理器统一返回错误码。这样既保留了完整链路，又不会过度包装。
对了，如果你想验证异常链是否正确，可以在测试环境用printStackTrace()打印一下，看看是否能从顶层异常一路追溯到原始cause。或者写个工具方法，递归获取所有cause并打印——这比线上出了问题再排查要靠谱得多。
你问所有异常都得包装成业务异常传递吗？其实不用这么死板。就拿底层技术异常来说吧，比如数据库连不上的SQLException，或者Redis缓存超时的RedisException，这种技术层面的错误，直接抛给上层业务开发同学，他们大概率看得一脸懵——“ORA-12170连接超时”是啥？和我现在开发的订单模块有啥关系？这时候包装成业务异常就很有必要，比如DAO层遇到SQL异常，就抛个OrderDaoException，message写“订单数据查询失败”，再把原始SQLException当cause传进去。我去年带新人的时候，有个小伙子直接在DAO层throw SQLException，结果Service层同事排查问题时，对着满屏的SQLState码抓瞎，后来改成业务异常后，大家一看异常类名就知道是订单DAO的问题，沟通效率至少提升了一半。
但要是同一业务层内部传递异常，就别瞎包装了。比如Service层调用另一个Service方法，像用户服务调用订单服务查历史订单，订单服务抛了个OrderNotFoundException，这时候用户服务直接把这个异常抛出去就行，没必要再包一层UserServiceException。我之前见过一个项目，Service层调用Service都要包一层新异常，结果异常链长得像裹脚布——Controller层拿到的异常，得调用五六次getCause()才能找到原始错误，日志里光异常堆栈就打印了三屏，排查的时候眼睛都快看瞎了。后来我们定了个规矩：同一业务域内的异常传递，能不包装就不包装，除非需要补充关键上下文（比如订单ID、用户ID），这才用新异常包装，现在日志清爽多了，排查问题平均时间从原来的两小时缩短到二十分钟。
异常链传递和普通的异常抛出有什么本质区别？
普通异常抛出如果直接使用throw new Exception(“错误信息”)，很可能会丢失原始异常的堆栈和根因信息，就像把快递盒上的原始面单撕掉重贴，导致后续排查时找不到最初的问题来源；而异常链传递通过initCause()方法或带cause参数的构造方法，让每个异常都保留“上一级异常”的引用，相当于给每个快递盒贴了“中转标签”，能完整串联从底层错误到顶层抛出的全链路轨迹，让根因追溯有迹可循。
如何在代码中获取异常链中的原始异常？
可以通过getCause()方法逐层获取。比如顶层异常对象e，调用e.getCause()能拿到它的直接原因异常；如果这个直接原因本身也是被包装的异常，继续调用e.getCause().getCause()，直到返回null（表示到达最原始的异常）。实际开发中 写个工具方法递归获取，比如：public static Throwable getRootCause(Throwable e) { while (e.getCause() != null) e = e.getCause(); return e; }，避免手动写多层getCause()的麻烦。
所有异常都需要包装成业务异常传递吗？
不是必须的。一般底层技术异常（比如数据库连接超时的SQLException、缓存读写失败的RedisException） 包装成业务异常，方便上层开发者理解（比如OrderDaoException比SQLException更贴近业务场景）；但如果是同一业务层内部的异常传递（比如Service层调用另一个Service方法），直接传递原始异常即可，过度包装（比如每层都包新异常）反而会让异常链过长，增加日志冗余和排查复杂度。
非受检异常和受检异常，在异常链传递中该怎么选？
优先用非受检异常（继承RuntimeException）。因为业务异常通常需要跨多层传递（DAO→Service→Controller），非受检异常不需要在方法签名加throws声明，能减少代码冗余；如果是必须强制处理的异常（比如文件操作后必须关闭流），可以用受检异常，但传递时同样要通过initCause()或带cause的构造方法保留原始异常，避免断链。核心原则是：无论哪种异常，传递时“不丢原始cause”比“是否受检”更重要。
线上排查时发现异常链日志很长，如何快速定位根因？
首先检查是否存在“过度包装”问题（比如同一业务流程中包了3层以上异常），这类情况需优化代码，减少不必要的包装； 日志打印时 用log.error(“错误信息”, e)（注意传异常对象e），主流日志框架（如Logback、Log4j2）会自动打印完整异常链，包括所有cause的堆栈； 可在日志中标记关键上下文（如订单ID、用户ID），比如throw new OrderException(“订单[12345]处理失败”, e)，这样即使链长，也能通过关键信息快速锁定问题场景。
