从try catch finally块中返回是不好的做法吗?

lom*_*axx 126 c# try-catch try-catch-finally

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

try
{
    x = SomeThingDangerous();
    return x;
}
catch (Exception ex)
{
    throw new DangerousException(ex);
}
finally
{
    CleanUpDangerousStuff();
}
Run Code Online (Sandbox Code Playgroud)

现在这段代码编译得很好并且可以正常工作,但是从try块中返回它感觉不对,特别是如果最终有关联的话.

我的主要问题是如果最终抛出它自己的例外会发生什么?你有一个返回的变量,但也有一个例外来处理...所以我有兴趣知道其他人在try块中返回的想法?

Meh*_*ari 164

不,这不是一个坏习惯.将return它放在有意义的地方可以提高可读性和可维护性,并使您的代码更易于理解.finally如果return遇到语句,您不应该关心块将被执行.


Ed *_* S. 18

无论如何都会被执行,所以没关系.

  • 不,实际上,它不仅仅是插件,还有一些异常称为异步异常,如StackOverflowException,ThreadAbortException和OutOfMemoryException,它们可能导致finally块不被执行.阅读有关约束执行区域以处理这些方案. (8认同)
  • 除非,当然,有一个System.exit(); 某处;-) (7认同)

小智 14

就个人而言,我会避免这种编码,因为我不想在最终陈述之前看到返回语句.

我的思维很简单,它可以线性地处理事物.因此,当我通过代码进行干运行时,我会倾向于认为一旦我能够达到返回语句,一切跟随无关紧要在这种情况下显然是错误的(不是它会影响返回语句但是副作用可能是什么).

因此,我会安排代码,以便return语句始终出现在finally语句之后.


Spe*_*ort 9

这可以回答你的问题

尝试中真正发生的事情{return x; } finally {x = null; 声明?

从阅读该问题看起来,如果您认为它可能会引发异常,那么您可以在finally语句中使用另一个try catch结构.编译器将确定何时返回该值.

也就是说,无论如何重组你的代码可能会更好,这样它以后就不会让你感到困惑,也可能是其他可能不知道这一点的人.

  • 我个人认为它使你的代码的可读性有点困难,仅此一点就足以让我找出构建代码的其他方法.但实际上这只是个人偏好. (3认同)
  • 我倾向于同意你的个人偏好:) (3认同)

Ife*_*ruo 5

功能上没有区别。

然而,不这样做是有原因的。具有多个退出点的较长方法通常更难以阅读和分析。但是这种反对意见更多地与 return 语句有关,而不是 catch 和 finally 块。