finally 总是执行且可能覆盖异常，不替代受检异常的处理义务，应优先使用 try-with-resources 管理资源并避免 finally 中 return。
面试中问到 finally 块与受检异常的交互，核心不是背概念，而是看清三点：finally 何时执行、它会不会干扰异常传播、以及它和受检异常在编译约束上的配合逻辑。
finally 总是执行，但可能“覆盖”异常
无论 try 中是否抛出受检异常（如 IOException），也无论 catch 是否捕获它，finally 块都会执行。这是 JVM 层面保障的行为，除非调用 System.exit() 或 JVM 崩溃。
关键细节在于：如果 finally 块里自己抛出了异常（比如 close() 失败），它会压制 try 或 catch 中原本未处理的受检异常，最终向外抛出的是 finally 的异常。例如：
- try 抛出
FileNotFoundException（受检） - catch 捕获并处理了它
- finally 中调用
resource.close()又抛出IOException（也是受检）→ 这个新异常会成为方法实际抛出的异常
受检异常必须被显式处理，finally 不改变这一规则
finally 本身不承担“处理受检异常”的义务。它只是执行清理代码的场所；而受检异常的强制处理要求，仍由 try-catch 或 throws 承担。
也就是说：
- 若 try 块内调用了声明抛出受检异常的方法（如
FileInputStream构造器），你必须用catch捕获，或在方法签名加throws IOException - 不能指望 “写了 finally 就算处理了受检异常”——编译器根本不认这个逻辑
- 常见错误写法：
try { new FileInputStream("x"); } finally { ... }→ 编译失败，缺少对IOException的处理
资源管理的最佳实践：优先用 try-with-resources
Java 7 引入的 try-with-resources 本质上是 try-finally 的语法糖，但它自动处理了资源关闭，并且能正确抑制（suppressed）多个异常中的次要异常。
相比手写 finally 关闭资源，它更安全、更简洁：
- 自动调用
close()，无需手动判空或嵌套 try - 若 try 块抛出异常，且
close()也抛异常，主异常保留，close()异常被“抑制”并可通过getSuppressed()获取 - 避免因 finally 内异常覆盖业务异常导致排查困难
return 语句在 finally 中的陷阱
如果 finally 块里有 return，它会直接终结方法执行，覆盖 try 或 catch 中的 return 值或抛出的受检异常。
例如：
- try 中
return 1; - catch 中
return 2; - finally 中
return 3;→ 方法永远返回 3，且任何受检异常都不会抛出
这在涉及受检异常的方法中尤其危险：可能让本该向上声明或处理的异常“静默消失”，破坏契约，编译器也无法检查。
