Java异常掩盖是try-with-resources保障异常信息不丢失的机制，主异常决定流程，抑制异常保留上下文；多资源关闭时因JVM需选一主异常，其余被suppressed；须显式检查getSuppressed()并记录，close()应抛异常而非吞掉，资源变量隐式final确保安全释放。
Java异常掩盖（Suppressed Exceptions）不是bug，而是try-with-resources在多资源场景下保障异常信息不丢失的机制。关键不在“避免掩盖”，而在“看清主次、安全取用”——主异常决定流程走向，抑制异常保留上下文细节，两者共同构成完整的错误真相。
多资源关闭时，为什么一定会出现Suppressed异常
当try块抛出异常，且多个资源的close()方法也各自抛出异常时，JVM必须选择一个异常作为最终抛出对象（否则语义混乱），其余异常就被标记为suppressed并附加到主异常上。这不是设计缺陷，而是确定性行为：
- 资源按声明逆序关闭：先声明的后关闭，后声明的先关闭；关闭顺序错误可能引发额外异常（如BufferedWriter关闭时底层OutputStream已关闭）
- 每个close()调用都是独立执行点，只要它抛异常，就可能被抑制
- 即使只有一个资源，若try块异常 + close()异常同时发生，也会产生1个suppressed异常
如何安全访问被抑制的异常信息
不能假设getSuppressed()返回空数组，也不能忽略其存在。生产环境需显式检查并记录：
- 在catch块中调用e.getSuppressed()获取Throwable数组，逐个打印message或完整stack trace
- 日志框架中建议使用结构化方式记录，例如：主异常：IOException: read timeout；抑制异常[0]：SQLException: connection closed
- 避免仅打印e.getMessage()，否则会完全丢失close阶段的问题线索
自定义资源类中close()方法的编写要点
close()是否抛异常，直接影响suppressed行为。务必注意：
立即学习“Java免费学习笔记（深入）”；
- 若close()逻辑可能失败（如网络连接强制断开、磁盘写满），应抛出具体异常（如IOException），而非静默吞掉
- 不要在close()中捕获并吞掉底层异常，除非你明确知道可以忽略——否则问题将彻底消失，无法被suppressed机制捕获
- 若资源关闭过程本身依赖其他资源（如释放锁、提交事务），需确保这些操作也遵循AutoCloseable契约，否则可能造成连锁抑制
变量作用域与资源安全释放的关系
try-with-resources括号内的变量是隐式final的，不可重新赋值。这点直接关系到资源是否真能被关闭：
- 错误写法：try (FileInputStream fis = new FileInputStream("a.txt")) { fis = new FileInputStream("b.txt"); } → 原fis对象未被关闭
- 正确做法：每个资源独立声明，不复用变量名；如需替换资源，应在try块内新建局部变量，但原资源仍会在作用域结束时关闭
- 资源变量在try块结束后立即不可访问，这既是语法限制，也是防止误用的安全屏障
