问题标签 [try-catch-finally]

最近我惊讶地发现在 Java 的 finally 块中可以有一个 return 语句。

似乎很多人认为按照“不要在 finally 子句中返回”中描述的那样做是一件坏事。再深入一点，我还发现“ Java 的返回并不总是”，它显示了 finally 块中其他类型的流控制的一些非常可怕的例子。

所以，我的问题是，谁能给我一个例子，在 finally 块中的 return 语句（或其他流控制）产生更好/更具可读性的代码？

除了语法，有什么区别

和

编辑：在.NET 2.0 中？

所以

在行为上是等价的吗？

考虑到这段代码，我是否可以绝对确定该finally块始终执行，无论something()是什么？

我见过有人说不带参数使用 catch 是不好的形式，特别是如果那个 catch 没有做任何事情：

但是，这被认为是好的形式：

据我所知，将清理代码放在 finally 块中和将清理代码放在 try..catch 块之后的唯一区别是，如果你的 try 块中有 return 语句（在这种情况下，finally 中的清理代码将运行，但 try..catch 之后的代码不会）。

不然最后有什么特别的？

所以今天早上我遇到了一些看起来像这样的代码：

现在这段代码编译得很好并且可以正常工作，但是从 try 块中返回感觉不正确，特别是如果有关联的 finally。

我的主要问题是如果 finally 抛出它自己的异常会发生什么？您有一个返回的变量，但也有一个要处理的异常......所以我很想知道其他人对从 try 块中返回的看法？

在对一些看起来像这样的代码进行故障排除时，我遇到了非常痛苦的故障排除经验：

这个问题很难解决，因为 doSomeStuff() 引发了异常，这反过来又导致 doSomeOtherStuff() 也引发了异常。第二个异常（由 finally 块抛出）被抛出到我的代码中，但它没有处理第一个异常（从 doSomeStuff() 抛出），这是问题的真正根本原因。

如果代码是这样说的，问题就会很明显：

所以，我的问题是：

在没有任何 catch 块的情况下使用 finally 块是众所周知的 java 反模式吗？（它当然似乎是众所周知的反模式“不要吞噬异常！”的一个不太明显的子类）

我正在使用以下单线程公寓。我无法从线程对象中回收内存/其他资源。Actullay 我想将我的线程包裹在 try catch 和 fianlly 块中。try 和 catch 完成了。但我不确定 finally 块。我需要在 finally 块中调用什么代码、属性或函数。

你是如何格式化你的try..catch.finally块的？尤其是当只将它包装在少量代码上时，它会破坏一切，使代码在我看来非常不可读和难看。

如：

这 7 行代码变成了 16 行代码。

关于更好的try..catch..finally格式的任何建议？

我很确定我已经知道答案，但是我仍然很好奇在处理 Try,Catch,Finally 块中的错误的意见是什么——但是当你重复自己时。

顺便说一句-我不是在谈论用户输入-而是以它为例，因为它清晰而简短

考虑一下这段代码......

假设我们有一个函数，如果它失败了，我们希望返回一条错误消息，因为异常无关紧要——我们的函数没有成功，用户不需要任何额外的细节。

我一直认为，如果您可以处理错误，请避免异常-因为它不再异常，但是我想知道关于避免重复自己的意见...您可以执行以下操作来避免重复你自己...

这不是最好的例子，但为了简洁起见，我想强调重复代码。

已知异常会导致性能损失，但是对于这种情况有什么想法呢？

如果您运行下面的代码，它实际上会在每次调用 goto 之后执行 finally：

为什么？