finally 块确保无论 try 是否抛出异常、catch 是否执行、甚至 catch 中再次抛出异常或执行 return，其中的代码都会被执行；而将等效逻辑写在 catch 之后则无法覆盖这些边界情况，极易导致资源泄漏或状态不一致。
在 Java 异常处理中，finally 块的设计初衷并非“锦上添花”，而是保障关键清理逻辑的绝对执行——这是 try-catch 后直接跟代码所无法提供的可靠性。
关键差异：执行确定性
以下三种典型场景会暴露 // C（位于 catch 后）与 finally { // C } 的本质区别：
✅ 场景 1：catch 块中抛出新异常
try {
throw new IOException("IO failed");
} catch (IOException e) {
System.out.println("Handled IO error");
throw new RuntimeException("Wrapped error"); // ← 新异常抛出
} finally {
System.out.println("Cleanup: closed resources"); // ✅ 执行
}
// System.out.println("Cleanup: closed resources"); // ❌ 永远不会执行！→ finally 中的清理代码仍会执行；而 // C 语句因异常传播被跳过。
✅ 场景 2：try 或 catch 中含 return 语句
public static String example() {
try {
return "from try";
} catch (Exception e) {
return "from catch";
} finally {
System.out.println("finally runs before return!"); // ✅ 总是先执行
}
}→ 即使 try 或 catch 提前返回，finally 仍会在方法真正退出前执行（注意：它不能改变已确定的返回值，但可修改对象状态或执行副作用）。
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
✅ 场景 3：未被捕获的异常（如 Error 或非匹配 Exception）
try {
throw new OutOfMemoryError(); // 不是 Exception 子类，且通常不被捕获
} catch (IOException e) {
// 不匹配，跳过
} finally {
System.out.println("Still cleaned up!"); // ✅ 执行
}→ 若 catch 无法捕获该异常（例如 Error、运行时异常未声明、或类型不匹配），// C 完全失效，而 finally 依然可靠。
最佳实践：资源管理首选 finally（或更优的 try-with-resources）
尽管 Java 7+ 推荐使用 try-with-resources（自动调用 close()），但 finally 仍是底层保障：
FileInputStream fis = null;
try {
fis = new FileInputStream("data.txt");
// 读取操作
} catch (IOException e) {
logger.error("Read failed", e);
} finally {
if (fis != null) {
try {
fis.close(); // 显式关闭，避免资源泄漏
} catch (IOException ignored) {
// 关闭异常通常忽略，但可记录
}
}
}⚠️ 注意事项：
- finally 中应避免抛出新异常（尤其当 try/catch 已有异常时），否则原始异常可能被掩盖（可用 addSuppressed() 保留上下文）；
- 不要在 finally 中使用 return（会覆盖 try/catch 的返回值，造成逻辑混乱）；
- 对于实现了 AutoCloseable 的资源，优先使用 try-with-resources，它本质是编译器自动插入 finally 调用 close()，更简洁安全。
总之，finally 是 Java 异常模型中实现确定性清理的基石——它不是“可选语法糖”，而是编写健壮、可维护系统代码的必备机制。
