我应该多久使用一下C#中的try和catch？

Question

在编写#1优先级永不崩溃的C#应用​​程序时,我应该多久使用一次try-catch块？

我可以在try-catch块中封装方法中的所有语句吗？

public void SomeMethod()
{
    try
    {
        // entire contents of the function
        // library calls
        // function calls
        // variable initialization .. etc
    }
    catch (Exception e)
    {
        // recover
    }
}

将一切包装在try-catch块中有什么缺点？

Answer 1

唯一的缺点是实际抛出异常.包装代码没有开销,除非发生异常.

此外,您不希望将try/catch用于控制流.考虑这个(错误的代码):

try {

    FileStream fs = File.Open("somefile.txt", FileMode.Open);

} catch (Exception ex) {
    MessageBox.Show("The file does not exist. Please select another file");
}

你会从File.Exists这样的东西中获得更多的性能.如:

if(!File.Exists("somefile.txt"))
  MessageBox.Show("The file does not exist.")

编辑:找到MSDN直接引用:

找到并设计出异常繁重的代码可以带来不错的性能.请记住,这与try/catch块无关:只有在抛出实际异常时才会产生成本.您可以根据需要使用尽可能多的try/catch块.无偿使用例外是您失去性能的地方.例如,您应该远离使用控制流异常之类的事情.

Answer 2

这是一个很大的话题.从这里开始,对异常处理最佳实践进行一些出色的讨论,并为宗教战争做好准备......

代码分析团队博客

马丁福勒 - 快速失败

MSDN上的异常处理

已检查与未经检查的例外情况

我自己的观点是,在大多数情况下,你使用"尝试/最终"很多,但"抓住"很少.问题是,如果您尝试在错误的实例中捕获并处理异常,则可能会无意中将应用程序置于错误状态.通常,使用dev和test来了解实际需要处理异常的位置.那些将是你无法检查的地方.即你不应该真正需要处理null引用或filenotfound因为你可以主动检查那些.只有您知道的例外情况可能会发生,但您无法做任何事情.除此之外,为了您的数据状态,让它崩溃.

如果您吞咽异常,通常意味着您不理解您的程序或您获得异常的原因.捕获System.Exception是代码味道的典型代表...

Answer 3

实际上,除了日志记录之外,我很少使用catch块.finally对我来说更常见.大多数时候,lock或using做我可以做的所有事情(事实上,这也是一个finally).

Eric Lippert有一篇关于可能有用的异常的博客文章.