摄自:这里

引发和捕获异常不应该作为方法成功执行的一部分常规发生。在开发类库时，必须让客户端代码有机会在执行可能引发异常的操作之前测试错误条件。例如，System.IO.FileStream提供了一个CanRead属性，可以在调用Read方法之前进行检查，以防止引发潜在的异常，如下所示的代码片段:

Dim str As Stream = GetStream() If (str.CanRead) Then '代码来读取流 如果

The decision of whether to check the state of an object prior to invoking a particular method that may raise an exception depends on the expected state of the object. If a FileStream object is created using a file path that should exist and a constructor that should return a file in read mode, checking the CanRead property is not necessary; the inability to read the FileStream would be a violation of the expected behavior of the method calls made, and an exception should be raised. In contrast, if a method is documented as returning a FileStream reference that may or may not be readable, checking the CanRead property before attempting to read data is advisable.

To illustrate the performance impact that using a "run until exception" coding technique can cause, the performance of a cast, which throws an InvalidCastException if the cast fails, is compared to the C# as operator, which returns nulls if a cast fails. The performance of the two techniques is identical for the case where the cast is valid (see Test 8.05), but for the case where the cast is invalid, and using a cast causes an exception, using a cast is 600 times slower than using the as operator (see Test 8.06). The high-performance impact of the exception-throwing technique includes the cost of allocating, throwing, and catching the exception and the cost of subsequent garbage collection of the exception object, which means the instantaneous impact of throwing an exception is not this high. As more exceptions are thrown, frequent garbage collection becomes an issue, so the overall impact of the frequent use of an exception- throwing coding technique will be similar to Test 8.05.

只要不抛出异常，示例之间的有效差异就可以忽略不计。

但是，如果在'try'子句中抛出异常，则第一个示例将完全忽略它。第二个示例将向调用堆栈的下一个步骤抛出异常，因此所述示例的区别在于，一个示例完全掩盖了任何异常(第一个示例)，而另一个示例(第二个示例)保留了异常信息，以便后续处理，同时仍然执行'finally'子句中的内容。

例如，如果您将代码放在第一个示例的'catch'子句中，该子句抛出异常(无论是最初引发的异常还是新抛出的异常)，则阅读器清理代码永远不会执行。最后执行，不管'catch'子句中发生了什么。

因此，'catch'和'finally'之间的主要区别是，'finally'块的内容(少数例外)可以被认为是保证执行的，即使面对意外的异常，而'catch'子句之后的任何代码(但在'finally'子句之外)都不会带有这样的保证。

顺便说一句，Stream和StreamReader都实现了IDisposable，并且可以包装在一个“using”块中。'Using'块在语义上等同于try/finally(没有'catch')，所以你的例子可以更简洁地表达为:

using (StreamReader reader = new  StreamReader("myfile.txt"))
{
  int i = 5 / 0;
}

.．.它会在StreamReader实例超出作用域时关闭并销毁它。 希望这能有所帮助。

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

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

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

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

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

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

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

如果你读过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();
}