finally 块的核心价值在于无论 try 是否抛出异常、catch 是否匹配、甚至 catch 中再次抛出异常或执行 return，finally 中的代码都保证执行，而写在 catch 后的普通代码则可能被跳过。
在 Java 异常处理中，finally 块并非语法装饰，而是保障资源安全与逻辑确定性的关键机制。表面上看，将清理代码（如关闭文件、释放锁、重置状态）写在 catch 之后似乎等价于放在 finally 中，但二者在控制流层面存在本质差异。
关键区别：执行的「确定性」
考虑以下三种典型场景，它们都会导致 // C（位于 catch 后的普通语句）不执行，而 finally { // C } 一定执行：
✅ 场景 1：try 中抛出未被捕获的异常
try {
throw new RuntimeException("uncaught"); // 未被 catch(...) 捕获（例如 catch 只捕获 IOException）
} catch (IOException e) {
// 不会进入
} finally {
System.out.println("Finally executed"); // ✅ 执行
}
System.out.println("After catch"); // ❌ 不执行 —— 程序在此前已抛出异常并向上传播✅ 场景 2：catch 块中主动抛出新异常
try {
throw new IOException();
} catch (IOException e) {
System.out.println("Caught");
throw new RuntimeException("from catch"); // 抛出新异常
} finally {
System.out.println("Cleanup done"); // ✅ 仍执行
}
// System.out.println("After catch"); // ❌ 永远不会到达✅ 场景 3：try 或 catch 中执行 return
public static String demo() {
try {
return "from try";
} catch (Exception e) {
return "from catch";
} finally {
System.out.println("Finally runs before return!"); // ✅ 先执行，再返回
// 注意：此处不能用 return 覆盖原返回值（除非是 void 方法），但副作用必发生
}
}? Java 规范明确：finally 总在 try 或 catch 中的 return、break、continue 语句实际完成前执行——这是 finally 最具价值的语义保证。
正确实践：用 finally 做确定性清理
FileInputStream fis = null;
try {
fis = new FileInputStream("data.txt");
// 读取操作...
} catch (IOException e) {
log.error("Read failed", e);
throw new ServiceException("File processing error");
} finally {
if (fis != null) {
try {
fis.close(); // ✅ 即使前面抛异常，这里仍尝试关闭
} catch (IOException ignored) {
// 关闭异常通常忽略，或记录为 warn
}
}
}
⚠️ 注意：自 Java 7 起更推荐使用 try-with-resources（自动资源管理），它隐式包含 finally 行为且更简洁安全：
try (FileInputStream fis = new FileInputStream("data.txt")) { // 使用 fis... } catch (IOException e) { // 处理异常 } // ✅ fis.close() 自动在 finally 中调用
总结
- finally 是 Java 提供的唯一能 100% 保证执行的代码块，适用于所有需要“无论如何都要运行”的逻辑（如资源释放、监控埋点、事务回滚标记）。
- 将等效代码写在 catch 后属于错误抽象——它只覆盖了“正常结束”和“被 catch 的异常”两种路径，却遗漏了未捕获异常、catch 再抛异常、提前返回等常见分支。
- 在现代 Java 开发中，优先使用 try-with-resources；对于非 AutoCloseable 资源或复杂清理逻辑，finally 仍是不可替代的底层保障机制。
