异常丢失陷阱：分析在 finally 块中抛出新异常导致 try 块原始异常被遮蔽（Masked）的避坑指南-Java面试题-PHP中文网

finally块抛异常会覆盖try中的原始异常，因JVM将新异常设为最终异常并丢弃原异常；避免方式包括：finally内捕获清理异常、用addSuppressed挂载、或改用try-with-resources。

异常丢失陷阱：分析在 finally 块中抛出新异常导致 try 块原始异常被遮蔽（masked）的避坑指南

finally块里抛异常，会直接盖掉try里的原始异常——这不是bug，是JVM规范行为。原始异常对象被丢弃，堆栈信息彻底消失，调试时只能看到“清理失败”，却找不到业务出错的真正原因。

为什么原始异常会被覆盖

Java虚拟机在执行try块时，若抛出异常，只是暂存该异常对象，并未立即传播。一旦进入finally块并触发throw语句，JVM就把这个新异常当作当前方法的“最终异常”，直接覆盖操作数栈中待传播的原始异常。原异常因无引用而被GC回收，物理级丢失。

不是IDE或编译器问题，所有JDK版本（包括JDK 17、21）均如此
return语句在finally中也会导致同样后果：异常被静默吞掉，程序看似正常退出
即使catch块已存在，只要finally抛异常，它仍会绕过catch，直接向上抛出

避免遮蔽的三种可靠写法

核心原则：finally里不抛异常、不return；若有清理风险，必须捕获并主动挂载为“被抑制异常”。

方案一：用try-catch包裹清理逻辑 在finally内对close()等可能抛异常的操作加一层try-catch，仅记录日志，绝不重抛
方案二：手动调用addSuppressed() 若原始异常已捕获（如在catch中），可在finally里捕获清理异常后，用originalException.addSuppressed(cleanupException)保留线索
方案三：改用try-with-resources 所有实现AutoCloseable的资源（如FileInputStream、Connection），自动在异常发生时把close()抛的异常作为suppressed异常附加到主异常上

哪些清理操作最容易踩坑

以下代码模式高频引发异常丢失，需特别警惕：

手动调用inputStream.close()、connection.close()，且未判空或未包try
finally中调用自定义的releaseResource()，内部含网络IO或文件操作
日志框架的shutdown()或flush()放在finally里，而它们可能抛InterruptedException
使用旧式JDBC连接管理（非DataSource），在finally中close()前未检查Connection是否为null

一个安全关闭资源的典型模板

兼顾兼容性与可读性，适用于JDK 7+：

FileInputStream fis = null;
Exception readException = null;
try {
    fis = new FileInputStream("data.txt");
    // 业务处理
} catch (IOException e) {
    readException = e;
} finally {
    if (fis != null) {
        try {
            fis.close();
        } catch (IOException closeEx) {
            if (readException != null) {
                readException.addSuppressed(closeEx);
            } else {
                readException = closeEx;
            }
        }
    }
    if (readException != null) {
        throw readException;
    }
}