构造器是设置异常cause的首选方式，initcause()仅为补救手段；自定义异常必须提供带throwable参数的构造器以支持异常链。

Throwable(String, Throwable)构造器和initCause()本质是同一件事的两种实现路径：都是为了给一个异常对象设置cause（根本原因），形成异常链。但它们的使用场景、安全性和语义清晰度差别很大。

构造器是首选方式，一步到位

当你创建异常时就知道原始异常是谁，就该直接用带cause参数的构造器：

• 语义明确：new RuntimeException("网络超时", e) 一眼看出这是包装行为
• 内部自动调用initCause(e)，且时机绝对安全（在fillInStackTrace()之前）
• 线程安全：对象创建即完成绑定，无竞态风险
• 框架兼容好：Spring、Logback等都依赖此标准模式解析上下文

initCause()是补救手段，有严格限制

它只适用于“异常对象已存在，但还没设cause，且又没法重造”的特殊情况：

• 必须满足 getCause() == null，否则抛IllegalStateException
• 只能调一次；重复调用或对已用构造器初始化过的对象调用，都会失败
• 典型场景：从AOP拦截器拿到一个空异常实例，之后才捕获到底层IOException，需动态挂因
• 不推荐用于日常异常包装——绕路、易错、可读性差

两者不能混用，更不能替代

下面这种写法是错的：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

RuntimeException e = new RuntimeException("fail");
e.initCause(cause);
throw e;

应该直接写成：

throw new RuntimeException("fail", cause);

前者多了一步、多一个失败点、还可能静默失效；后者简洁、可靠、符合JDK设计本意。

自定义异常必须提供带cause的构造器

如果你写MyException，只写了MyException(String)，没写MyException(String, Throwable)，那别人就无法构建异常链——等于主动废掉了Java异常链机制。正确做法是：

• 继承Exception或RuntimeException
• 显式声明两个构造器：MyException(String) 和 MyException(String, Throwable)
• 后者内部调用super(message, cause)

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南