`try-finally` 里的 `return`：为什么 `finally` 会悄悄改掉返回值、吞掉异常

前言

try-finally 大家天天写，但下面这段代码的返回值，能一眼答对的人不多：

public int getValue() {
    int x = 1;
    try {
        return x;      // 这里 return 的是 1？
    } finally {
        x = 2;         // finally 又把 x 改成了 2
    }
}

返回 1 还是 2？

更刁钻的是，如果 finally 里也写了 return，或者 finally 里抛了异常，会发生什么？这些不是脑筋急转弯，而是真实项目里踩过的坑——尤其"finally 吞掉异常"，能让一个本该炸出来的错误悄无声息地消失，排查起来能让人怀疑人生。

这篇文章讲清楚 finally 和 return、异常之间那些容易被忽略的执行细节。

环境说明：本文基于 JDK 8。

---

一、先复现

复现 1：finally 改了变量，返回值却没变

先揭晓开头那题的答案：

public static int getValue() {
    int x = 1;
    try {
        return x;
    } finally {
        x = 2;
    }
}
// 调用：System.out.println(getValue());

1

返回的是 1，不是 2。 finally 里明明把 x 改成了 2，返回值却还是 1。很反直觉。

复现 2：finally 里加个 return，结果就变了

只把 finally 里的赋值换成 return：

public static int getValue2() {
    int x = 1;
    try {
        return x;         // 想返回 1
    } finally {
        return 2;         // finally 里也 return
    }
}

2

这次返回的是 2。try 里的 return x 好像被 finally 的 return 覆盖了。

复现 3：finally 里的 return 把异常吞了

最危险的一个：

public static int getValue3() {
    try {
        throw new RuntimeException("出错了！");   // 抛异常
    } finally {
        return -1;                               // finally 里 return
    }
}

-1

注意：程序正常返回了 -1，那个 RuntimeException 凭空消失了！ 调用方完全不知道里面出过错。这就是臭名昭著的"finally 吞异常"。

三个现象，指向同一组问题：finally 到底在什么时候、以什么顺序执行？它为什么能改返回值、吞异常？

---

二、根因

一句话总纲：try 里的 return 并不是"立刻返回"，它会先把返回值"暂存"起来，然后一定要等 finally 执行完，才真正返回。 finally 就是在这个"暂存之后、真正返回之前"的空档里插了一脚。

2.1 复现 1：返回值在 return 那一刻就被"定格"了

return x 的执行分两步：

1. 计算并暂存返回值：把 x 当前的值（1）复制到一个临时位置（可以理解为"返回值寄存器"），这个值此刻就定格了；
2. 执行 finally；
3. 真正返回那个暂存的值。

关键在于：finally 里的 x = 2 改的是局部变量 x，而返回值早在第 1 步就已经被复制走、和 x 脱钩了。所以改 x 影响不到已经暂存的返回值 1。

小坑提醒：如果返回的是对象引用，情况有点不同。暂存的是"引用（地址）“，finally 里若通过这个引用去修改对象内部的属性，改动是生效的（因为对象是同一个）；但若在 finally 里让变量指向一个新对象，则不影响已暂存的旧引用。记住：暂存的是"那一刻的值/引用”。

2.2 复现 2 和 3：finally 里的 return 会"抢占"返回

如果 finally 里自己也有 return，就完全是另一回事了：finally 的 return 会直接终止方法，用它自己的返回值覆盖掉 try 里暂存的那个，并且丢弃 try 中待处理的 return 或异常。

• 复现 2：try 暂存了返回值 1，但 finally 执行到 return 2 时，直接带着 2 结束方法——暂存的 1 被丢弃。
• 复现 3：try 里抛出的异常本应向上传播，但 finally 执行到 return -1，方法直接正常返回 -1——那个正在传播的异常被丢弃了，调用方永远收不到。

道理是一致的：finally 里的 return（或 throw）会"截胡"，让 try 里原本要返回的值、要抛的异常统统作废。 异常被吞，就是这么发生的。

---

三、正解：finally 只做清理，别在里面 return、别在里面抛异常

这些坑的根源，都是在 finally 里做了"改返回值/中断控制流"的事。规避原则很简单：

finally 块只用来做资源清理（关流、解锁、还连接），绝不放 return、throw，也不去修改要返回的变量。

// 反例：finally 里 return，吞掉异常
public int bad() {
    try {
        return riskyCall();
    } finally {
        return -1;            // ✗ 吞掉 riskyCall 的返回值和异常
    }
}

// 正解：finally 只清理，让返回值和异常正常传播
public int good() throws Exception {
    Resource r = open();
    try {
        return r.process();   // 返回值/异常都能正常出去
    } finally {
        r.close();            // ✓ 只做清理
    }
}

更进一步，如果只是为了关资源，优先用 try-with-resources（JDK 7+）。它会自动、安全地关闭资源，代码更短，也没有手写 finally 的这些坑：

// 最推荐：try-with-resources 自动关闭，无需手写 finally
public int best() throws Exception {
    try (Resource r = open()) {
        return r.process();
    }
}

如果确实需要在清理阶段处理异常，也应该在 finally 里 try-catch 住并记录日志，而不是让它中断主流程或吞掉主异常。

---

四、常见误区与面试高频问答

Q：finally 一定会执行吗？

绝大多数情况会，包括 try 里有 return、break、continue、抛异常时。唯二的例外：一是执行到 System.exit() 直接终止 JVM；二是线程被强制杀死或断电这类极端情况。正常代码里，可以认为"finally 必定执行"。

Q：try 有 return、finally 也有 return，最终返回哪个？

finally 的。finally 里的 return 会覆盖 try（或 catch）里的 return，并丢弃待抛的异常。正因如此，别在 finally 里写 return。

Q：为什么 finally 改了变量，返回值没变？

因为 return x 在执行时就把 x 的值复制到返回值暂存位置了，返回的是那个副本。finally 里改 x 改的是变量本身，和已经复制出去的返回值无关。（返回对象引用时，改对象内部属性会生效，改引用指向不生效。）

Q：finally 里抛异常会怎样？

如果 try 里也抛了异常，finally 里的新异常会覆盖掉 try 里的原始异常向上抛出——原始异常（往往是更关键的那个）就丢了。所以 finally 里的代码也要保证不抛异常，或自己 try-catch 处理掉。

---

总结

try-finally 遇上 return 和异常，几个容易被忽略的点：

• try 里的 return 会先把返回值暂存，再执行 finally，最后返回暂存的值——所以 finally 改局部变量，改不动已经暂存的返回值。
• finally 里如果有 return 或 throw，会截胡：覆盖 try 的返回值、并吞掉 try 中正在传播的异常——这是异常凭空消失的元凶。
• 正解：finally 只做清理，不写 return、不抛异常、不改返回变量；关资源优先用 try-with-resources。

一句话记忆： try 的 return 先定格返回值再走 finally；finally 里千万别 return，否则它会悄悄改掉返回值、吞掉异常。finally 只配做清理。