从 try catch finally 块中返回是不好的做法吗？
所以今天早上我遇到了一些代码，看起来像这样：
try
{
x = SomeThingDangerous();
return x;
}
catch (Exception ex)
{
throw new DangerousException(ex);
}
finally
{
CleanUpDangerousStuff();
}
现在这个代码编译得很好并且可以正常工作，但是从 try 块中返回感觉不太正确，特别是如果有一个关联的finally。
我的主要问题是如果最后抛出它自己的异常会发生什么？ 你有一个返回的变量，但也有一个异常需要处理......所以我有兴趣知道其他人对从 try 块中返回有什么看法？
So I came across some code this morning that looked like this:
try
{
x = SomeThingDangerous();
return x;
}
catch (Exception ex)
{
throw new DangerousException(ex);
}
finally
{
CleanUpDangerousStuff();
}
Now this code compiles fine and works as it should, but it just doesn't feel right to return from within a try block, especially if there's an associated finally.
My main issue is what happens if the finally throws an exception of it's own? You've got a returned variable but also an exception to deal with... so I'm interested to know what others think about returning from within a try block?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
不，这不是一个坏习惯。 将
return放在有意义的地方可以提高可读性和可维护性，并使代码更易于理解。 您不必关心，因为如果遇到return语句，finally块就会被执行。No, it's not a bad practice. Putting
returnwhere it makes sense improves readability and maintainability and makes your code simpler to understand. You shouldn't care asfinallyblock will get executed if areturnstatement is encountered.不管怎样finally都会被执行，所以无所谓。
The finally will be executed no matter what, so it doesn't matter.
就我个人而言，我会避免这种编码，因为我不喜欢在finally语句之前看到return语句。
我的头脑很简单，处理事情的方式相当线性。 因此，当我浏览干运行的代码时，我会倾向于认为，一旦我可以到达 return 语句，接下来的一切都无关紧要，这在这种情况下显然是非常错误的（并不是说它会影响 return 语句，而是可能有什么副作用）。
因此，我会安排代码，使 return 语句始终出现在 finally 语句之后。
Personally, I would avoid this kind of coding as I don't feel like seeing return statements before finally statements.
My mind is simple and it process things rather linearly. Therefore when I walk through the code for dry running, I will have tendency to think that once I can reach the return statement, everything follow doesn't matter which obviously is pretty wrong in this case (not that it would affect the return statement but what the side effects could be).
Thus, I would arrange the code so that the return statement always appear after the finally statements.
这可能会回答您的问题
到底发生了什么在尝试{返回x; } 最后 { x = null; } 语句？
从阅读该问题来看，如果您认为它可能会引发异常，您可以在finally 语句中使用另一个try catch 结构。 编译器会计算出何时返回该值。
也就是说，无论如何重组你的代码可能会更好，这样它就不会在以后让你或其他可能不知道这一点的人感到困惑。
This may answer your question
What really happens in a try { return x; } finally { x = null; } statement?
From reading that question it sounds like you can have another try catch structure in the finally statement if you think it might throw an exception. The compiler will figure out when to return the value.
That said, it might be better to restructure your code anyway just so it doesn't confuse you later on or someone else who may be unaware of this as well.
功能上没有区别。
然而，不这样做是有一个原因的。 具有多个退出点的较长方法通常更难以阅读和分析。 但这种反对更多地与 return 语句有关，而不是与 catch 和 finally 块有关。
Functionally there is no difference.
However there is one reason for not doing this. Longer methods with several exit points are often more difficult to read and analyze. But that objection has more to do with return statements than catch and finally blocks.
在您的示例中，两种方式都是等效的，如果编译器生成相同的代码，我什至不会感到惊讶。 如果finally 块中发生异常，无论将return 语句放在块内还是块外，都会遇到相同的问题。
真正的问题是从风格上来说哪种是最好的。 我喜欢编写我的方法，以便只有一个 return 语句，这样更容易看到方法的流程，因此我也喜欢将 return 语句放在最后，这样很容易看出它是方法结束以及它返回的内容。
我认为，由于 return 语句与最后一个语句一样整齐地放置，因此其他人不太可能将多个 return 语句撒入该方法的其他部分。
In your example either way is equivalent, I wouldn't even be suprised if the compiler generated the same code. If an exception happens in the finally block you have the same issues whether you put the return statement in block or outside of it.
The real question is stylistically which is best. I like to write my methods so that there is only one return statement, this way it is easier to see the flow out of the method, it follows that I also like to put the return statement last so it is easy to see that it is the end of the method and this what it returns.
I think with the return statement so neatly placed as the last statement, others are less likely to come and sprinkle multiple returns statements into other parts of the method.