应优先在自定义异常构造函数中声明Throwable cause参数并调用super(message, cause)，若无双参构造则用initCause()补救（仅限未设cause时调用一次）；JDK 1.4+内置异常已支持，自定义类需手动添加。
Java中如何用 initCause() 和构造函数构建异常链
异常链不是自动产生的，必须显式传递原始异常。最常用方式是通过带 Throwable 参数的构造函数，比如 new IOException("读取失败", cause)。如果自定义异常类没提供该构造函数，就只能用 initCause() 补救——但仅限未设置过 cause 的实例，且只能调用一次。
常见错误是忽略父类是否已支持 cause 传递：JDK 自带异常（如 IOException、RuntimeException）从 Java 1.4 起都内置了双参构造函数；而你自己写的异常类默认没有，必须手动添加。
- 优先在自定义异常构造函数中声明
Throwable cause参数，并调用super(message, cause) - 避免在已设 cause 后再调
initCause()，否则抛IllegalStateException - 若需兼容老 JDK（initCause() 替代方案
自定义异常类必须重写哪些构造函数
只要继承 Exception 或 RuntimeException，至少应提供以下四个构造函数，覆盖所有常见调用场景：
public class DataValidationException extends Exception {
public DataValidationException() {
super();
}
public DataValidationException(String message) {
super(message);
}
public DataValidationException(String message, Throwable cause) {
super(message, cause);
}
public DataValidationException(Throwable cause) {
super(cause);
}
}
漏掉任意一个，都可能让调用方无法正确包装异常。例如，只留无参和单参构造函数，当上游想用 new DataValidationException("格式错", e) 时就会编译失败。
立即学习“Java免费学习笔记（深入）”；
-
Throwable cause构造函数不可省略——这是异常链的入口 - 单参
String构造函数最常用，别忘了 - 无参构造函数虽少用，但某些序列化或框架反射机制会依赖它
异常链在日志和调试中实际怎么被展开
调用 e.printStackTrace() 或记录 e.toString() 时，JVM 会自动递归打印 getCause() 链，直到返回 null。但注意：只有直接 cause 才会被默认展开；嵌套更深的（比如 cause 的 cause）需手动调用 getCause().getCause() 才能看到。
真实场景中容易踩坑的是日志框架（如 Logback）。默认配置下，logger.error("处理失败", e) 会完整输出整个链；但如果写成 logger.error("处理失败: " + e.getMessage(), e)，就可能因字符串拼接丢失堆栈上下文。
- 永远用
logger.error(msg, throwable)形式，而非拼接e.getMessage() - IDE 调试时，展开
e.cause字段可逐层查看原始异常 -
getCause()返回null表示链终止，不代表没发生异常
为什么 throws 声明不检查异常链深度
throws 只校验方法签名中声明的异常类型是否覆盖了实际抛出的**顶层异常**，完全不关心它的 cause 是什么类型。也就是说，即使你抛出 new ServiceException("DB异常", new SQLException(...))，也只需在方法上声明 throws ServiceException，无需额外加 SQLException。
这个设计意味着：异常链是运行时行为，编译器不管。但反过来说，也导致调用方容易忽略底层 cause 的语义——比如把网络超时当成普通业务失败处理。
- 不要指望
throws提醒你处理深层 cause - 关键路径上建议用
instanceof或getCause()显式判断特定底层异常 - 过度嵌套（>3 层）会让问题定位变模糊，应控制链长度
