Java中try/catch-finally块的作用探究：两种写法的差异分析

首先明确：finally块的核心价值是确保特定代码无论try/catch块的执行路径如何（除了极少数极端情况），都会被执行。你提到的两段代码，在常规无异常、无提前退出的场景下看起来一致，但在很多关键场景下差异巨大，具体如下：

差异场景1：try/catch块中存在return语句 #

如果try块里直接return：

• 代码段1（带finally）：执行A → 执行finally里的C → 再执行return退出方法
• 代码段2（无finally）：执行A → 直接return，后面的C完全不会执行

示例代码：

// 代码段1执行结果：A → C
try {
    System.out.println("A");
    return;
} catch(Exception e) {
    System.out.println("B");
} finally {
    System.out.println("C");
}

// 代码段2执行结果：A（C不会执行）
try {
    System.out.println("A");
    return;
} catch(Exception e) {
    System.out.println("B");
}
System.out.println("C");

同理，如果catch块里写了return，代码段1的C依然会执行，代码段2的C则会被跳过。

差异场景2：try块抛出未被catch捕获的异常 #

如果try里抛出了catch无法处理的异常（比如Error或者未声明的检查型异常）：

• 代码段1：执行A → 抛出异常 → 执行finally里的C → 异常继续向上传播
• 代码段2：执行A → 抛出异常 → 直接跳出try/catch块，C完全不会执行

差异场景3：catch块中抛出新异常 #

如果catch块处理完原有异常后，又抛出了新的异常：

• 代码段1：执行A → 执行B → 执行C → 抛出新异常
• 代码段2：执行A → 执行B → 抛出新异常，C不会执行

finally块的核心用途 #

正是因为上述特性，finally块几乎是资源清理的标准写法：比如关闭IO流、释放数据库连接、解锁同步锁等，确保这些资源无论代码是否异常、是否提前退出，都能被正确释放，避免资源泄漏。

例外情况：极少数finally不执行的场景 #

只有当代码调用System.exit(0)（直接终止JVM）、或者JVM突然崩溃（比如硬件故障）时，finally块才不会执行，这属于极端特殊情况。

内容的提问来源于stack exchange，提问作者tweetysat