我同意这里的共识——空的“catch”是不好的，因为它掩盖了try块中可能发生的任何异常。

此外，从可读性的角度来看，当我看到一个“try”块时，我假设会有一个对应的“catch”语句。如果你只使用'try'来确保在'finally'块中分配资源，你可以考虑使用'using'语句:

using (StreamReader reader = new StreamReader('myfile.txt'))
{
    // do stuff here
} // reader.dispose() is called automatically

你可以对任何实现IDisposable的对象使用'using'语句。对象的dispose()方法在块的末尾被自动调用。

如果你读过c#，你就会明白finally块是为了优化应用程序和防止内存泄漏而设计的。

CLR并不能完全消除泄漏……如果程序无意中保留了对不需要的对象的引用，就会发生内存泄漏

例如，当您打开一个文件或数据库连接时，您的机器将分配内存来处理该事务，除非执行了dispose或close命令，否则该内存将不会被保留。但是如果在事务处理期间发生了错误，则继续执行的命令将被终止，除非它在try..最后. .块。

Catch与finally的不同之处在于，Catch的设计目的是为您提供处理/管理或解释错误的方法。把它想象成一个人告诉你“嘿，我抓住了一些坏人，你想让我对他们做什么?” 而最终的目的是确保你的资源被正确地配置。想想某人，不管有没有坏人，他都会确保你的财产仍然安全。

你应该让他们俩永远合作下去。

例如:

try
{
  StreamReader reader=new  StreamReader("myfile.txt");
  //do other stuff
}
catch(Exception ex){
 // Create log, or show notification
 generic.Createlog("Error", ex.message);
}
finally   // Will execute despite any exception
{
  reader.Close();
}

可能有很多原因，其中之一就是异常执行非常慢。如果这种情况经常发生，很容易缩短执行时间。

try/catch块捕获所有异常的问题是，如果发生未知异常，您的程序现在处于不确定状态。这完全违背了快速失败规则——如果发生异常，您不希望程序继续运行。上面的try/catch甚至会捕获outofmemoryexception，但这绝对是程序不会在其中运行的状态。

Try/finally块允许您在快速失败的情况下执行清理代码。对于大多数情况，您只想在全局级别捕获所有异常，以便您可以记录它们，然后退出。

“Finally”是一个声明，“你必须总是做一些事情来确保程序状态正常”。因此，如果存在异常可能会抛出程序状态，那么拥有一个异常总是很好的形式。编译器还会竭尽全力确保Finally代码运行。

“Catch”是“我可以从这个异常中恢复”的声明。您应该只从真正可以纠正的异常中恢复—不带参数的catch表示“嘿，我可以从任何异常中恢复!”，这几乎总是不正确的。

如果有可能从每个异常中恢复，那么它就真的是语义上的吹毛求疵，关于你所声明的意图是什么。然而，事实并非如此，而且几乎可以肯定的是，在你上面的框架能够更好地处理某些异常。因此，使用finally，让您的清理代码免费运行，但仍然让更有知识的处理程序来处理问题。

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

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