finally块抛出unchecked异常会覆盖try/catch中的原始异常，导致调试困难、日志缺失和上下文断裂；因不受编译检查，易被忽视；推荐用日志记录替代抛异常，或使用try-with-resources。
finally块里抛出 unchecked 异常，会直接覆盖 try 或 catch 中已发生的异常，调用方只能看到 finally 抛出的那个异常，原始异常信息彻底丢失。
会掩盖原始异常
如果 try 块中已经抛出一个异常（比如 NullPointerException），catch 块没重新 throw，但 finally 里又 throw 了另一个 unchecked 异常（比如 IllegalArgumentException），那么外部捕获到的只有 finally 的异常，原始异常被静默丢弃。
- 这导致调试困难：堆栈跟踪指向 finally，但问题根源在 try 里
- 日志里看不到原始异常，排查时容易误判
- 即使 catch 块做了日志记录，也无法弥补上下文断裂
不受编译检查约束
unchecked 异常（如 RuntimeException 及其子类）不需要声明 throws，也不强制 try-catch。所以 finally 中 throw 它们，编译器不会提醒你风险，但运行时影响真实存在。
- 不像 checked 异常那样有语法约束，更容易被忽略
- 开发者可能误以为“只是个运行时异常，影响不大”，实际破坏了异常传播链
替代方案更安全
真需要在 finally 中报告问题，优先选择记录日志 + 正常完成，而不是抛异常：
立即学习“Java免费学习笔记（深入）”；
- 用 logger.error("资源关闭失败", e) 记录异常，不 throw
- 若必须中断流程，考虑在 finally 外统一处理，或改用 try-with-resources（自动关闭，不鼓励手动 throw）
- 实在要抛，应确保 finally 不会掩盖主逻辑异常——比如只在无异常时才检查并抛出
这种行为不是 bug，是 Java 规范明确规定的执行顺序：finally 执行时若抛出新异常，就会终止当前方法并向上抛出它，原异常不再传递。
