关键是在抛出新异常时显式传入原异常作为cause参数，如throw new runtimeexception("业务失败", e)；自定义异常需提供带cause的构造函数并调用super(message, cause)，否则链断裂；堆栈中出现“caused by:”即表示链生效。
在 catch 中捕获异常后，若要通过异常链保留原始堆栈，关键是在抛出新异常时**显式传入原异常作为 cause 参数**，而不是只用 message 或忽略 cause。Java 的 Throwable 构造函数支持将原异常作为 cause 传入，JVM 会自动维护异常链，并在打印堆栈时显示 Caused by: 层级。
使用带 cause 参数的构造函数
绝大多数标准异常（如 RuntimeException、IllegalArgumentException）和自定义异常都提供接受 Throwable cause 的构造方法。只要调用它，就能建立异常链：
-
正确做法：
throw new RuntimeException("业务处理失败", originalException); -
错误做法：
throw new RuntimeException("业务处理失败");（丢失原始堆栈） -
也错误：
throw new RuntimeException(originalException.getMessage());（仅复制消息，无堆栈、无链）
确保自定义异常支持 cause
如果自己定义异常类，需显式提供接收 cause 的构造函数，并调用父类对应构造器：
public class ServiceException extends Exception {
public ServiceException(String message, Throwable cause) {
super(message, cause); // 关键：把 cause 传给父类
}
}
否则即使你在 throw 时写了 cause，也不会被保存——因为构造函数没转发。
避免“吞掉”原始异常的常见陷阱
以下写法看似合理，实则切断了异常链：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 仅记录日志后
return或静默吞掉异常（原始异常彻底丢失） - 重新 new 一个异常但未传 cause，例如：
throw new ServiceException("校验失败"); - 用
e.printStackTrace()输出后抛出新异常却不带 cause（日志有，链没了）
真正需要的是“包装再抛出”，不是“替代再抛出”。
验证异常链是否生效
可通过 getCause() 获取原始异常，或直接打印堆栈观察：
try {
riskyOperation();
} catch (IOException e) {
throw new RuntimeException("读取配置失败", e); // 包装
}
运行后堆栈输出会类似：
java.lang.RuntimeException: 读取配置失败
at com.example.App.main(App.java:12)
Caused by: java.io.IOException: 文件不存在
at java.base/java.io.FileInputStream.open0(Native Method)
...
只要看到 Caused by: 行，就说明异常链完整保留了原始堆栈。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
