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

📅 2026/7/31 15:28:56
`try-finally` 里的 `return`:为什么 `finally` 会悄悄改掉返回值、吞掉异常
前言try-finally大家天天写但下面这段代码的返回值能一眼答对的人不多publicintgetValue(){intx1;try{returnx;// 这里 return 的是 1}finally{x2;// finally 又把 x 改成了 2}}返回1还是2更刁钻的是如果finally里也写了return或者finally里抛了异常会发生什么这些不是脑筋急转弯而是真实项目里踩过的坑——尤其finally吞掉异常能让一个本该炸出来的错误悄无声息地消失排查起来能让人怀疑人生。这篇文章讲清楚finally和return、异常之间那些容易被忽略的执行细节。环境说明本文基于 JDK 8。一、先复现复现 1finally改了变量返回值却没变先揭晓开头那题的答案publicstaticintgetValue(){intx1;try{returnx;}finally{x2;}}// 调用System.out.println(getValue());1返回的是1不是2。finally里明明把x改成了2返回值却还是1。很反直觉。复现 2finally里加个return结果就变了只把finally里的赋值换成returnpublicstaticintgetValue2(){intx1;try{returnx;// 想返回 1}finally{return2;// finally 里也 return}}2这次返回的是2。try里的return x好像被finally的return覆盖了。复现 3finally里的return把异常吞了最危险的一个publicstaticintgetValue3(){try{thrownewRuntimeException(出错了);// 抛异常}finally{return-1;// finally 里 return}}-1注意程序正常返回了-1那个RuntimeException凭空消失了调用方完全不知道里面出过错。这就是臭名昭著的finally吞异常。三个现象指向同一组问题finally到底在什么时候、以什么顺序执行它为什么能改返回值、吞异常二、根因一句话总纲try里的return并不是立刻返回它会先把返回值暂存起来然后一定要等finally执行完才真正返回。finally就是在这个暂存之后、真正返回之前的空档里插了一脚。2.1 复现 1返回值在return那一刻就被定格了return x的执行分两步计算并暂存返回值把x当前的值1复制到一个临时位置可以理解为返回值寄存器这个值此刻就定格了执行finally真正返回那个暂存的值。关键在于finally里的x 2改的是局部变量x而返回值早在第 1 步就已经被复制走、和x脱钩了。所以改x影响不到已经暂存的返回值1。小坑提醒如果返回的是对象引用情况有点不同。暂存的是引用地址“finally里若通过这个引用去修改对象内部的属性改动是生效的因为对象是同一个但若在finally里让变量指向一个新对象则不影响已暂存的旧引用。记住暂存的是那一刻的值/引用”。2.2 复现 2 和 3finally里的return会抢占返回如果finally里自己也有return就完全是另一回事了finally的return会直接终止方法用它自己的返回值覆盖掉try里暂存的那个并且丢弃try中待处理的return或异常。复现 2try暂存了返回值1但finally执行到return 2时直接带着2结束方法——暂存的1被丢弃。复现 3try里抛出的异常本应向上传播但finally执行到return -1方法直接正常返回-1——那个正在传播的异常被丢弃了调用方永远收不到。道理是一致的finally里的return或throw会截胡让try里原本要返回的值、要抛的异常统统作废。异常被吞就是这么发生的。三、正解finally只做清理别在里面return、别在里面抛异常这些坑的根源都是在finally里做了改返回值/中断控制流的事。规避原则很简单finally块只用来做资源清理关流、解锁、还连接绝不放return、throw也不去修改要返回的变量。// 反例finally 里 return吞掉异常publicintbad(){try{returnriskyCall();}finally{return-1;// ✗ 吞掉 riskyCall 的返回值和异常}}// 正解finally 只清理让返回值和异常正常传播publicintgood()throwsException{Resourceropen();try{returnr.process();// 返回值/异常都能正常出去}finally{r.close();// ✓ 只做清理}}更进一步如果只是为了关资源优先用try-with-resourcesJDK 7。它会自动、安全地关闭资源代码更短也没有手写finally的这些坑// 最推荐try-with-resources 自动关闭无需手写 finallypublicintbest()throwsException{try(Resourceropen()){returnr.process();}}如果确实需要在清理阶段处理异常也应该在finally里try-catch住并记录日志而不是让它中断主流程或吞掉主异常。四、常见误区与面试高频问答Qfinally一定会执行吗绝大多数情况会包括try里有return、break、continue、抛异常时。唯二的例外一是执行到System.exit()直接终止 JVM二是线程被强制杀死或断电这类极端情况。正常代码里可以认为finally必定执行。Qtry有return、finally也有return最终返回哪个finally的。finally里的return会覆盖try或catch里的return并丢弃待抛的异常。正因如此别在finally里写return。Q为什么finally改了变量返回值没变因为return x在执行时就把x的值复制到返回值暂存位置了返回的是那个副本。finally里改x改的是变量本身和已经复制出去的返回值无关。返回对象引用时改对象内部属性会生效改引用指向不生效。Qfinally里抛异常会怎样如果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先定格返回值再走finallyfinally里千万别return否则它会悄悄改掉返回值、吞掉异常。finally只配做清理。