为什么try{…}最后{…}好;尝试{…} catch{}坏?

我见过有人说，使用不带参数的catch是一种糟糕的形式，尤其是当catch什么都不做的时候:

StreamReader reader=new  StreamReader("myfile.txt");
try
{
  int i = 5 / 0;
}
catch   // No args, so it will catch any exception
{}
reader.Close();

然而，这被认为是良好的形式:

StreamReader reader=new  StreamReader("myfile.txt");
try
{
  int i = 5 / 0;
}
finally   // Will execute despite any exception
{
  reader.Close();
}

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

否则，最后有什么特别的?

当前回答

因为当这一行引发异常时，你不会知道。

对于第一个代码块，异常将被简单地吸收，即使程序的状态可能是错误的，程序也将继续执行。

对于第二个块，将抛出异常并出现冒泡，但reader.Close()仍然保证运行。

如果不期望出现异常，那么就不要使用try. catch块，这样当程序进入糟糕的状态而你不知道原因时，就很难进行调试。

其他回答

如果您不知道要捕获什么异常类型或如何处理它，那么使用catch语句是没有意义的。你应该把它留给上级，他们可能对情况有更多的了解，知道该怎么做。

在那里仍然应该有一个finally语句，以防出现异常，这样就可以在异常抛出给调用者之前清理资源。

首先，捕获您懒得处理的异常是一种糟糕的实践。请参阅《改进。net应用程序性能和可伸缩性》中关于. net性能的第5章。旁注，您可能应该在try块中加载流，这样，如果它失败，您就可以捕获相关异常。在try块之外创建流会破坏它的目的。

Try{…}catch{}并不总是坏的。这不是一种常见的模式，但当我无论如何都需要关闭资源时，我倾向于使用它，比如在线程末尾关闭(可能)打开的套接字。

从可读性的角度来看，它更明确地告诉未来的代码读者“这里的东西很重要，无论发生什么都需要完成。”这很好。

此外，空catch语句对它们来说往往有某种“味道”。它们可能表明开发人员没有仔细考虑可能发生的各种异常以及如何处理它们。

最后无论如何都会执行。如果你的try块成功，它就会执行，如果你的try块失败，它就会执行catch块，然后是finally块。

此外，最好尝试使用以下结构:

using (StreamReader reader=new  StreamReader("myfile.txt"))
{
}

由于using语句被自动包装在try / finally语句中，流将自动关闭。(如果想要真正捕获异常，则需要在using语句周围加上try / catch)。

推荐文章