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

时间:2009-01-16 00:31:20

标签: c# try-catch try-catch-finally

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

try
{
    x = SomeThingDangerous();
    return x;
}
catch (Exception ex)
{
    throw new DangerousException(ex);
}
finally
{
    CleanUpDangerousStuff();
}

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

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

6 个答案:

答案 0 :(得分:161)

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

答案 1 :(得分:17)

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

答案 2 :(得分:14)

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

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

因此,我会安排代码,以便return语句总是出现在finally语句之后。

答案 3 :(得分:9)

这可以回答你的问题

What really happens in a try { return x; } finally { x = null; } statement?

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

也就是说,不管怎么说重组你的代码可能会更好,这样以后就不会让你感到困惑,或者其他人也可能没有意识到这一点。

答案 4 :(得分:4)

功能上没有区别。

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

答案 5 :(得分:3)

在你的例子中,无论哪种方式都是等价的,如果编译器生成相同的代码,我甚至不会感到惊讶。如果在finally块中发生异常,则无论是将return语句放在块中还是在块外部都存在相同的问题。

真正的问题是风格上最好的。我喜欢编写我的方法,这样只有一个return语句,这样就更容易看到方法的流出,接下来我也想把return语句放在最后,所以很容易看出它是方法的结束和它返回的内容。

我认为将return语句如此巧妙地放在最后一个语句中,其他人不太可能将多个return语句撒到方法的其他部分。