java异常链需显式传cause参数，否则getcause()返回null；正确做法是用带throwable参数的构造函数，initcause()仅作补救；常见断链原因包括未传cause、原始异常cause为null、fillinstacktrace()重置cause。
Java里怎么用 throw 把原始异常包进新异常里
直接抛出新异常时丢掉原始异常，是链式异常失效的最常见原因。Java从1.4起就支持异常链，但必须显式传入cause参数，否则getCause()返回null。
正确做法是在构造新异常时，把原始异常作为第二个参数传进去：
try {
riskyOperation();
} catch (IOException e) {
throw new RuntimeException("文件处理失败", e); // ✅ 传了e
}
错误写法（丢失上下文）：
throw new RuntimeException("文件处理失败"); // ❌ e没传进去
-
RuntimeException、IllegalArgumentException等非检查异常，都有带Throwable参数的构造函数 - 检查异常如
SQLException也大多支持，但得查Javadoc确认——不是所有自定义异常都实现了 - 如果目标异常类没提供
cause构造函数，就别硬套；要么换异常类型，要么手动调用initCause()（仅限未初始化过的异常实例）
什么时候该用 initCause() 而不是构造函数
只有在异常对象已经创建、但还没抛出，且构造函数不支持传cause时，才轮到initCause()出场。它是个补救手段，不是首选。
立即学习“Java免费学习笔记（深入）”；
典型场景：某些老库抛出的自定义异常类没实现带cause的构造器，你又不能改源码。
- 必须在异常被抛出前调用，且只能调用一次；重复调用会抛
IllegalStateException -
initCause()返回this，可链式调用，但实际很少这么用 - 绝大多数标准异常和现代框架异常（如Spring的
DataAccessException）都优先走构造函数路径，别绕弯
getCause() 返回 null 的三种真实原因
日志里看到getCause() == null，不代表没发生异常链——只是链断了。常见断点有三个：
- 新异常构造时根本没传
cause（最常见） - 原始异常本身是
NullPointerException或ArrayIndexOutOfBoundsException这类JVM自动抛出的异常，它们的cause默认为null，即使你把它当cause传进去，链也会“看起来”断掉（实际没断，只是源头没因） - 中间某层异常调用了
fillInStackTrace()并重置了cause（极少见，多见于代理或AOP拦截器里手动操作异常对象）
验证是否真断链，别只看getCause()，用printStackTrace()或日志框架的%xEx格式输出完整堆栈——链式异常的嵌套堆栈会原样保留。
Spring项目里 @Transactional 怎么影响异常链
Spring事务代理会在方法抛出异常后做两件事：回滚事务 + 可能包装异常。默认情况下，它只对RuntimeException和Error回滚，且不会动异常本身；但一旦配置了rollbackFor或用了TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，事情就变复杂。
- 如果事务切面捕获异常后重新抛出（比如做了日志），又没把原始异常设为
cause，链就断了 - Spring Data JPA 的
JpaTransactionManager在转换PersistenceException时，通常会保留cause，但第三方JDBC驱动（如旧版MySQL Connector/J）可能吞掉原始SQLException细节 - 最稳妥的做法：在
@Transactional方法内，自己完成异常包装，别依赖框架代劳
链式异常不是银弹，它依赖每一层都守规矩。最容易被忽略的是：你以为上层框架帮你链好了，其实它悄悄新建了一个没cause的异常扔出来。
