我见过有人说，使用不带参数的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块之后的代码将不会运行)。
否则，最后有什么特别的?
当前回答
使用Try…Catch . .最后，如果您的方法知道如何在本地处理异常。异常发生在Try中，在Catch中处理，然后在Finally中完成清理。
如果你的方法不知道如何处理异常，但需要在异常发生后进行清理，请使用Try..最后
通过这种方式，异常被传播到调用方法，如果调用方法中有任何合适的Catch语句，则进行处理。如果当前方法或任何调用方法中没有异常处理程序，则应用程序将崩溃。
最后，确保在将异常传播到调用方法之前完成了本地清理。
其他回答
“Finally”是一个声明，“你必须总是做一些事情来确保程序状态正常”。因此，如果存在异常可能会抛出程序状态，那么拥有一个异常总是很好的形式。编译器还会竭尽全力确保Finally代码运行。
“Catch”是“我可以从这个异常中恢复”的声明。您应该只从真正可以纠正的异常中恢复—不带参数的catch表示“嘿，我可以从任何异常中恢复!”，这几乎总是不正确的。
如果有可能从每个异常中恢复，那么它就真的是语义上的吹毛求疵，关于你所声明的意图是什么。然而，事实并非如此，而且几乎可以肯定的是，在你上面的框架能够更好地处理某些异常。因此，使用finally，让您的清理代码免费运行，但仍然让更有知识的处理程序来处理问题。
finally块仍然会抛出任何引发的异常。最后要做的就是确保在抛出异常之前运行清理代码。
The try..catch with an empty catch will completely consume any exception and hide the fact that it happened. The reader will be closed, but there's no telling if the correct thing happened. What if your intent was to write i to the file? In this case, you won't make it to that part of the code and myfile.txt will be empty. Do all of the downstream methods handle this properly? When you see the empty file, will you be able to correctly guess that it's empty because an exception was thrown? Better to throw the exception and let it be known that you're doing something wrong.
另一个原因是这样做的try. catch是完全错误的。你这样做的意思是，“无论发生什么，我都能处理好。”StackOverflowException呢，你能在那之后清理吗?OutOfMemoryException呢?一般来说，您应该只处理您期望并知道如何处理的异常。
最大的区别是尝试…Catch将吞下异常，隐藏发生错误的事实。Try .finally将运行您的清理代码，然后异常将继续运行，由知道如何处理它的程序来处理。
使用Try…Catch . .最后，如果您的方法知道如何在本地处理异常。异常发生在Try中，在Catch中处理，然后在Finally中完成清理。
如果你的方法不知道如何处理异常，但需要在异常发生后进行清理，请使用Try..最后
通过这种方式，异常被传播到调用方法，如果调用方法中有任何合适的Catch语句，则进行处理。如果当前方法或任何调用方法中没有异常处理程序，则应用程序将崩溃。
最后，确保在将异常传播到调用方法之前完成了本地清理。
因为当这一行引发异常时，你不会知道。
对于第一个代码块，异常将被简单地吸收，即使程序的状态可能是错误的，程序也将继续执行。
对于第二个块，将抛出异常并出现冒泡，但reader.Close()仍然保证运行。
如果不期望出现异常，那么就不要使用try. catch块，这样当程序进入糟糕的状态而你不知道原因时，就很难进行调试。
