异常链的核心目标是不丢失原始异常，Java 1.4起通过带cause构造函数或initCause()实现；优先使用带cause构造函数，避免重复设置cause导致异常；Caused by标识链路生效，提升日志与调试效率；包装需语义清晰、信息充分，避免无意义多层封装。
异常链的核心目标是不丢失原始异常，让上层能顺着异常堆栈一路追溯到最初出错的根源。Java 从 1.4 开始原生支持异常链，关键在于用 initCause() 或带 Throwable cause 参数的构造函数把原始异常“挂”到新异常上。
优先使用带 cause 的构造函数
这是最简洁、最安全的方式，尤其适用于自定义异常或调用标准异常构造器时。
- 多数内置异常（如
IllegalArgumentException、IOException）都提供String message, Throwable cause的重载构造函数 - 直接传入原始异常，JVM 自动建立链路，
getCause()和打印堆栈时都会正确展示 - 避免重复调用
initCause()导致IllegalStateException（因为有些异常内部已设过 cause）
慎用 initCause()，仅在必要时补救
当异常对象已创建、但尚未设置 cause，且该异常类未被 final 修饰、也未在构造中锁定 cause 时，才考虑用 initCause()。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 典型场景：捕获异常后做了部分处理（如日志记录），再包装成另一个类型异常抛出，但该异常类只提供了无参或单参构造器
- 调用前务必确认
getCause() == null，否则会抛出运行时异常 - 不是所有异常都允许二次设置 cause；例如
NullPointerException和RuntimeException子类若未显式支持，调用会失败
异常链在日志和调试中的实际价值
堆栈跟踪里出现 Caused by: 行，就是异常链生效的标志。它让问题定位不再依赖人工拼接日志。
- IDE 调试时，可逐层展开
cause查看各环节上下文 - 日志框架（如 Logback、Log4j2）默认格式化输出完整链路，无需额外配置
- 服务间调用中，若 RPC 框架保留了 cause（如 gRPC 的
StatusRuntimeException），下游也能看到原始业务异常，而非仅仅网络层包装
注意异常类型与语义一致性
包装异常不是为了掩盖问题，而是为了增强表达力。不要把 SQLException 直接套个 RuntimeException 就抛出去。
- 推荐做法：用语义更明确的业务异常包装，比如
OrderCreationFailedException包住底层OptimisticLockException - 确保新异常的消息包含关键线索（如操作意图、ID、阶段），而不仅复述 cause 的消息
- 避免多层无意义包装，如
AException → BException → CException → SQLException，中间两层没提供新信息，反而干扰溯源
