Java异常的链式传递与捕获_技术教程

异常链是Java中通过Throwable cause构造器或initCause()实现的嵌套异常机制，用于封装底层异常；需用printStackTrace()或getCauses()递归获取完整链，try-with-resources还支持suppressed异常。

什么是异常链（Exception Chaining）

Java 中的异常链，指的是一个异常在抛出时携带了另一个异常作为“原因”（cause），形成嵌套关系。这常见于封装底层异常、避免暴露实现细节的场景，比如 SQLException 包装成自定义的 DataAccessException。

关键点在于：不是所有异常都自动支持链式传递；必须显式调用带 Throwable cause 参数的构造函数，或使用 initCause() 方法（不推荐，仅限无法直接构造时）。

RuntimeException、IOException 等标准异常类，大多提供 Throwable cause 构造器
自定义异常若想支持链式，需在构造器中调用 super(cause)
直接 throw 一个已有异常（如 throw e;）不会创建新链，只是重抛——原堆栈和 cause 都保留

如何正确捕获并保留原始异常信息

捕获后简单打印 e.getMessage() 或 e.toString() 会丢失 cause 和完整堆栈，这是最常见误操作。

真正保留链式信息的方式是：

用 e.printStackTrace() —— 输出完整嵌套堆栈（含 cause 及其堆栈）
用 Throwable.getCause() 手动提取原因，再递归遍历（适合日志结构化处理）
用 Throwable.getStackTrace() + getCause() 组合构建自定义错误报告

例如，在日志中记录全链：

logger.error("Operation failed", e); // SLF4J / Log4j 会自动展开 cause

但若手动拼字符串，务必调用 e.printStackTrace(new PrintWriter(stringWriter))，而非只取 getMessage()。

try-with-resources 与异常抑制（Suppressed Exceptions）

Java 7 引入的 try-with-resources 在关闭资源时若抛出异常，且主异常已存在，则新异常会被“抑制”（suppressed），而不是覆盖原异常。这是另一种形式的链式关联，但机制不同。

关键行为：

只有在 try 块已抛出异常的前提下，close() 抛出的异常才会被抑制
被抑制的异常可通过 e.getSuppressed() 获取，返回 Throwable[]
printStackTrace() 默认会输出 suppressed 异常（JDK 7+）
不要在 catch 块里对资源调用 close() —— 这会导致重复关闭、可能抛出二次异常，干扰抑制逻辑

示例中若 InputStream 的 read() 抛异常，且 close() 也失败，后者将被抑制：

try (InputStream is = new FileInputStream("data.txt")) {
    int b = is.read(); // 抛 IOException
} catch (IOException e) {
    // e 包含被抑制的 close() 异常（如果有）
}

链式异常的调试陷阱

IDE（如 IntelliJ）默认只展开第一层异常堆栈，容易让人误以为 cause 没有被设置，或者忽略 suppressed 异常。

排查时注意：

在断点处用调试器展开 e.cause 字段，别只看 e.stackTrace
检查 e.suppressedExceptions（或调用 getSuppressed()），尤其在使用 try-with-resources 后
避免在 catch 块中新建异常却不传 cause，例如：throw new ServiceException("DB error"); —— 这彻底丢失原始上下文
Logback/Log4j2 默认格式化器会输出 cause，但 JSON 日志处理器（如 logstash-logback-encoder）需显式配置 includeContext=true 才包含 suppressed 异常