应优先在自定义异常构造函数中声明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免费学习笔记（深入）”；
酷纬企业网站管理系统Kuwebs是酷纬信息开发的为企业网站提供解决方案而开发的营销型网站系统。在线留言模块、常见问题模块、友情链接模块。前台采用DIV+CSS，遵循SEO标准。 1.支持中文、英文两种版本，后台可以在不同的环境下编辑中英文。 3.程序和界面分离，提供通用的PHP标准语法字段供前台调用，可以为不同的页面设置不同的风格。 5.支持google地图生成、自定义标题、自定义关键词、自定义描
-
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 层）会让问题定位变模糊，应控制链长度
