被压制的异常是try块抛出主异常后，资源close()再抛出并自动addSuppressed到主异常的次要异常；需调用getSuppressed()显式获取，遍历时应先判断数组长度且不可忽略多资源场景下的多个压制项。
Java中try-with-resources语句会在资源自动关闭时，把关闭过程中抛出的异常“压制”（suppressed）到主异常上，而不是覆盖它。理解并正确处理被压制的异常，是写出健壮资源管理代码的关键。
什么是被压制的异常
当try块中发生异常，且资源关闭时又抛出另一个异常，Java会将关闭异常作为“被压制异常”添加到主异常中，而不是丢弃或覆盖。主异常仍被抛出，但可通过getSuppressed()方法获取所有被压制的异常。
例如：
try (FileInputStream fis = new FileInputStream("a.txt")) {throw new RuntimeException("读取失败");
} catch (Exception e) {
System.out.println("主异常: " + e.getMessage());
for (Throwable s : e.getSuppressed()) {
System.out.println("被压制: " + s.getMessage());
}
}
如何安全地访问被压制的异常
调用getSuppressed()前应确保异常对象非null，且该方法返回的是不可变数组（长度可能为0），无需额外判空数组本身。
立即学习“Java免费学习笔记（深入）”；
- 始终在捕获异常后检查
e.getSuppressed().length > 0再遍历 - 不要假设只有1个被压制异常；多个资源关闭失败时可能有多个
- 日志中建议同时打印主异常和所有被压制异常的堆栈（用
printStackTrace()或日志框架的log.error(msg, e)通常已自动包含）
避免压制异常掩盖关键问题
被压制异常默认不显示在标准堆栈跟踪中，容易被忽略。尤其当主异常是业务无关的（如NPE），而被压制的是IO异常时，排查会困难。
- 开发阶段开启详细日志，或在catch块中主动记录被压制异常
- 单元测试中可断言
e.getSuppressed()是否为空，验证资源关闭逻辑是否健壮 - 若关闭逻辑本身可能失败（如网络流、数据库连接），考虑在close()内做防御性处理（如记录warn日志但不抛异常），避免无意义压制
自定义资源类时注意close()契约
实现AutoCloseable接口时，close()方法应尽量不抛出检查异常；若必须抛出，应声明throws Exception（而非具体检查异常），否则无法用于try-with-resources。
- 推荐close()只抛
RuntimeException或不抛异常 - 若close()中发生可恢复错误（如刷盘失败但内存已更新），优先记录warn日志，而非抛异常
- 确保close()幂等：多次调用不产生副作用，也不重复抛异常
