在Java中，finally块抛异常会覆盖try或catch中的原始异常，导致错误信息丢失；应避免在finally中抛出异常，改用try-catch包裹清理逻辑、try-with-resources（支持抑制异常）或日志记录。
在 Java 中，finally 块里抛出异常是不安全的，它可能覆盖 try 或 catch 中已经发生的异常，导致原始错误信息丢失，这是典型的“异常覆盖”问题。
finally 中抛异常会掩盖原有异常
当 try 或 catch 块中已发生异常，且 finally 块又抛出新异常时，JVM 会直接将 finally 的异常向上抛出，而 原异常会被静默丢弃（除非手动处理）。这会让调试变得困难——你看到的只是 finally 的异常，却不知道最初出错在哪。
- try 中抛出 NullPointerException
- catch 捕获并记录日志（未 throw）
- finally 中因资源关闭失败抛出 IOException
- 最终调用方只收到 IOException，NullPointerException 彻底消失
正确做法：避免在 finally 中抛检查异常
finally 应专注于清理工作（如关闭流、释放锁），不建议主动 throw 异常。若清理操作可能失败（如 close() 抛 IOException），应：
- 用 try-catch 包裹清理逻辑，内部处理或记录异常，但不向外抛
- 使用 try-with-resources（Java 7+），让编译器自动插入 finally 关闭逻辑，并支持抑制异常（suppressed exception）
- 若必须反馈清理失败，可通过日志记录，而非中断主流程
try-with-resources 自动处理异常覆盖
该语法会在资源关闭异常发生时，将关闭异常作为 suppressed exception 附加到主异常上，原始异常仍为主异常，可通过 getSuppressed() 获取被抑制的异常。这样既不丢失上下文，又保持语义清晰。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
示例：try (FileInputStream fis = new FileInputStream("a.txt")) {
int b = fis.read();
if (b == -1) throw new RuntimeException("读取失败");
} // 若 read() 后 close() 失败，IOException 会被抑制，RuntimeException 仍是主异常
特殊场景：finally 中需要“强制”报错怎么办？
极少数情况下（如关键校验失败必须中断），可考虑：
- 先检查是否已有异常（通过 Thread.currentThread().getStackTrace() 等间接判断不推荐，不可靠）
- 更稳妥的方式是把逻辑移到 catch 末尾或单独方法中，由业务层统一决策是否继续抛异常
- 避免依赖 finally 的执行顺序来控制异常流向
