Java中应使用带Throwable cause参数的异常构造方法包装底层异常，确保堆栈可追溯且语义清晰；自定义异常需显式调用super(message, cause)；须根据上下文选择合适异常类型，避免无意义同类型包装。
在 Java 中，捕获底层异常后将其作为 cause 构造新异常抛出，核心是利用支持 Throwable cause 参数的异常构造方法，并确保新异常的堆栈信息清晰反映“原始错误 + 业务上下文”的分层关系。
使用带 cause 的构造函数
绝大多数标准异常（如 RuntimeException、IllegalArgumentException、IOException 等）都提供接受 String message, Throwable cause 的构造方法。这是最直接、推荐的方式：
- 捕获原始异常后，用它作为 cause 创建更具语义的新异常
- JVM 会自动将 cause 的堆栈跟踪附加到新异常中（通过
printStackTrace()可看到 “Caused by:” 区块） - 调用
getCause()可安全获取原始异常，便于日志分析或条件处理
示例：
try {FileInputStream fis = new FileInputStream("config.txt");
} catch (FileNotFoundException e) {
throw new RuntimeException("配置文件加载失败", e); // e 作为 cause
}
确保 cause 不被意外丢弃
避免以下常见错误写法：
-
不要只传 message：如
throw new RuntimeException("配置文件加载失败")—— 原始异常信息完全丢失 -
不要手动拼接消息并忽略 cause：如
throw new RuntimeException("配置文件加载失败: " + e.getMessage())—— 堆栈和类型信息全无 -
自定义异常时必须显式调用父类含 cause 的构造器：若继承
Exception或RuntimeException，需在自己的构造方法中调用super(message, cause)
在自定义异常中正确支持 cause
如果你定义了自己的异常类，务必提供接收 Throwable cause 的构造方法，并委托给父类：
public ConfigLoadException(String message, Throwable cause) {
super(message, cause); // 关键：传递 cause
}
}
这样使用者才能像标准异常一样使用：throw new ConfigLoadException("初始化配置失败", e);
注意运行时异常与检查异常的语义差异
选择新异常类型要符合上下文职责：
- 若原始异常是
IOException（检查异常），而当前方法不希望声明 throws，可包装为RuntimeException或其子类（如UncheckedIOException） - 若属于业务逻辑错误（如参数无效导致解析失败），更适合用
IllegalArgumentException并传入 cause，既保留根因，又明确语义 - 避免无意义地层层包装成同类型异常（如把
SQLException包成另一个SQLException），应升级为更上层的业务异常
