在Java中异常链是什么_Java异常包装机制解析

异常链是Throwable类内置的因果追踪机制，通过带cause参数的构造函数创建，用于跨层封装、补充上下文和受检转非受检异常，日志需用logger.error(msg, e)才能显示Caused by。

异常链不是Java的“新功能”，而是从 Throwable 类诞生起就内置的因果追踪机制：一个异常可以明确声明“我是由另一个异常引起的”，并通过 getCause() 逐层回溯，最终在日志里呈现为带 Caused by: 的嵌套堆栈。

怎么创建异常链？只用对构造函数传参

最可靠、最常用的方式，就是使用带 Throwable cause 参数的异常构造函数：

• new RuntimeException("业务失败", e) —— 推荐，JDK 所有标准异常都支持，内部自动调用 initCause(e)
• new MyException("订单处理异常", e) —— 前提是你的自定义异常类显式提供了该构造方法，并把 cause 传给 super(message, cause)
• 避免手动调用 initCause(e)：它要求在 fillInStackTrace() 之前执行，而这个时机难控制，容易静默失败或抛 IllegalStateException

什么场景必须用异常链？三类不包装就丢根的问题

不是所有 catch 都要包装，但以下情况不用异常链，等于主动抹掉故障定位线索：

• 跨技术层级封装：比如 DAO 层抛出 SQLException，Service 层转成 BusinessException，不传 e 就只剩 “操作失败”，连 SQL 错误码、连接超时还是语法错误都看不到
• 补充关键业务上下文：原始异常是 SocketTimeoutException，你包装成 PaymentTimeoutException("支付超时，订单ID=ORD-20260112-889")，日志里一眼锁定问题单据
• 受检异常转非受检：方法签名不能声明 IOException，又不能吞掉它，就用 RuntimeException("加载配置失败", ioEx) 包装后抛出，既合规又保信息

为什么日志里没看到 Caused by:？常见失效原因

异常链“建了但看不见”，基本是这几个低级但高频的坑：

• throw new RuntimeException(e.getMessage()) —— 只取了消息字符串，e 的类型、堆栈、SQLState 全丢了
• 自定义异

  

  常漏写 MyException(String, Throwable) 构造器，别人一包装就退化成普通异常
• 重复包装同一异常：A 层已用 ServiceException("xxx", sqlEx) 包了一次，B 层又接住它再包成 ApiException("yyy", serviceEx)，结果堆栈里出现两层 Caused by:，第二层其实是包装异常本身，不是根源
• 日志打印方式不对：只写 logger.error("出错了", e.getMessage())，正确姿势是 logger.error("出错了", e)（Logback/SLF4J 会自动输出全链）

public class ServiceException extends Exception {
    public ServiceException(String message) {
        super(message);
    }
    public ServiceException(String message, Throwable cause) {
        super(message, cause); // 必须这行！否则链断
    }
}

异常链真正的难点不在“会不会用”，而在“在哪停”——链太短，信息不足；链太深（超过 3 层），反而掩盖真正根源。多数时候，只在抽象边界（DAO→Service→API）和语义跃迁（技术异常→业务异常）处包装一次就够了。