blocks|key|1556569|text|将控制结构和返回添加到finally{}块只是“因为你可以”滥用的另一个例子，这种滥用实际上分散在所有开发语言中。Jason的建议是正确的，它很容易成为维护的噩梦-反对函数提前返回的论点更适用于这种“延迟返回”的情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1556570|Finally块的存在只有一个目的，那就是允许您完全清理自己，而不管前面的代码中发生了什么。这主要是关闭/释放文件指针、数据库连接等，尽管我可以看到它被延伸到添加定制审计。|1556571|任何影响函数返回的东西都应该在try{}块中。即使你有一个方法，你检查了一个外部状态，做了一个耗时的操作，然后再次检查该状态，以防它变得无效，你仍然希望在try{}中进行第二次检查-如果它位于finally{}中，并且long操作失败，那么你将不必要地第二次检查该状态。|1556572|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Adding control structures and returns to finally{} blocks are just another example of "just because you can" abuses which are scattered throughout virtually all development languages. Jason was right in suggesting it could easily become a maintenance nightmare - the arguments against early returns from functions apply more-so to this case of "late returns".

Finally blocks exist for one purpose, to allow you to completely tidy up after yourself, no matter what happened in all the preceeding code. Principally this is closing / releasing file pointers, database connections etc., though I could see it being stretched to say adding in bespoke auditing.

Anything that affects the return of the function should lie in the try{} block. Even if you had a method whereby you checked an external state, did a time consuming operation, then checked that state again in case it became invalid, you would still want the second check inside the try{} - if it sat inside finally{} and the long operation failed, you would then be checking that state a second time needlessly.

blocks|key|1771752|text|如果你使用-Xlint:finally，javac最终会警告你返回。最初javac不会发出警告--如果代码出了问题，它应该无法编译。不幸的是，向后兼容意味着无法禁止意料之外的巧妙愚蠢。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1771753|可以从finally块抛出异常，但在这种情况下，所展示的行为几乎肯定是您想要的。|1771754|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

javac will warn of return in finally if you use the -Xlint:finally. Originally javac emitted no warnings - if something is wrong with the code, it should fail to compile. Unfortunately backwards compatibility means that unanticipated ingenious foolishness cannot be prohibited.

Exceptions can be thrown from finally blocks, but in that case the exhibited behaviour is almost certainly what you want.

blocks|key|1771847|text|几年前，我真的很难追查到一个由它引起的bug。代码类似于：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1771848|Object+problemMethod()+{
++++Object+rtn+=+null;
++++try+{
++++++++rtn+=+somethingThatThrewAnException();
++++}
++++finally+{
++++++++doSomeCleanup();
++++++++return+rtn;
++++}
}|code-block|syntax|javascript|1771849|发生的情况是，在其他代码中抛出了异常。它被捕获、记录并在somethingThatThrewAnException()方法中重新抛出。但是异常并没有通过problemMethod()向上传播。经过很长一段时间的研究，我们终于找到了返回方法。finally块中的返回方法基本上阻止了try块中发生的异常向上传播，即使它没有被捕获。|offset|length|style|CODE|1771850|正如其他人所说，虽然根据Java规范，从finally块返回是合法的，但这是一件坏事，不应该这样做。|1771851|entityMap^0|0|0|S|V|24|F|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]|$I|V|J|W|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

I had a REALLY hard time to track down a bug years ago that was caused by this. The code was something like:

<pre><code>Object problemMethod() {
 Object rtn = null;
 try {
 rtn = somethingThatThrewAnException();
 }
 finally {
 doSomeCleanup();
 return rtn;
 }
}
</code></pre>

What happened is that the exception was thrown down in some other code. It was being caught and logged and rethrown within the <code>somethingThatThrewAnException()</code> method. But the exception wasn't being propagated up past <code>problemMethod()</code>. After a LONG time of looking at this we finally tracked it down to the return method. The return method in the finally block was basically stopping the exception that happened in the try block from propagating up even though it wasn't caught.

Like others have said, while it is legal to return from a finally block according to the Java spec, it is a BAD thing and shouldn't be done.

I was surprised recently to find that it's possible to have a return statement in a finally block in Java.

It seems like lots of people think it's a bad thing to do as described in '<a href="https://web.archive.org/web/20070922061412/http://weblogs.java.net/blog/staufferjames/archive/2007/06/_dont_return_in.html" rel="noreferrer">Don't return in a finally clause</a>'. Scratching a little deeper, I also found '<a href="https://web.archive.org/web/20190528011825/http://www.cs.arizona.edu/projects/sumatra/hallofshame/" rel="noreferrer">Java's return doesn't always</a>' which shows some pretty horrible examples of other types of flow control in finally blocks.

So, my question is, can anyone give me an example where a return statement (or other flow control) in a finally block produces better / more readable code?

Returning from a finally block in Java

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

最近我很惊讶地发现，在Java中可以在finally块中使用return语句。似乎很多人认为像“”中描述的那样做是一件坏事。再深入一点，我还发现了'‘，它在finally块中显示了一些非常可怕的其他类型的流控制示例。所以，我的问题是，谁能给我一个例子，在finally块中的return语句(或其他流控制)可以产生更好的...

问在Java中从finally块返回
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Java中从finally块返回EN