1、异常处理的总体指导思想
学习C#中的异常处理机制，大概要了解以下几点：
- 首先，我们需要知道的事所有具体异常都是继承自System.Exception基类的。
- 其次，要熟悉FCL类库内置好的一些异常，例如：FileNotFoundException。
- 最后，不仅要懂得catch异常还要懂得throw异常
在实际动手写异常处理构造之前，首先要大概猜测一下可能会出现什么异常，既然可能发生异常，就意味着肯定存在着不稳定的因素。例如文件IO、网络IO、数据库操作、跟其他程序的交互（包括跟操作系统的交互）等等。由于.NET平台本身的安全设计，那些仅需要CPU、内存的操作往往不大可能出现异常，例如字符串处理操作。如果连这类操作都出现异常说明CPU或内存出现问题了，那么这是.NET平台能不能正常运行还是一回事呢，在应用中处理异常也就多半没什么用了。
那么为何要catch异常呢？主要有几个方面：对用户友好、隐藏敏感信息（比如数据库连接字符串）、增强稳定性（比如对于某些不稳定的操作catch之后再重试几次）、记录日志以便在不能调试的时候获取异常信息。
其实，大部分开发框架中都内置了最顶层的异常处理事件，例如，WinForm中有Application.ThreadException事件、MVC中可以通过Fitler机制实现，这样的话代码中除非要特殊处理才catch，那些尚未预计到的bug就可以通过异常处理事件捕获，不用到处写try...catch。
在catch之后还要懂的throw异常。考虑下面两种情形：
- 考虑输入验证的场景，例如用户输入的email格式不对，这时底层抛出的异常直接传递给顶层的调用者（即和用户交互的UI层），这样调用者可以拿这些异常信息决定如何告知用户。
- 在向顶层抛到过程中，catch异常之后继续抛。之所以要catch也许是因为又发生了其他异常，然后包装一下将它们都抛出去；也许是需要记录一下日志。
2、实例讲解异常处理
下面让我们以本文的一个例子及《.NET中的异常处理机制(二)》中的一个例子来说明如何处理异常。
为什么要处理异常呢？让我们从一个简单的例子看。从一个文本文件读取数据然后打印到控制台上。
public sealed class Program
{
public static void Main()
{
StreamReader streamReader = new StreamReader(@"c:data.txt");
Console.WriteLine(streamReader.ReadToEnd());
streamReader.Close();
}
}
如上图的代码，如果不处理异常，那么程序在运行时就会抛出一个FileNotFoundException，然后跟着一大堆该异常的相关信息。这些异常信息对于开发人员也许不是什么问题，但是对于没有.NET相关背景知识的终端用户来说，这就是大麻烦了，因为用户不理解这些信息，这些信息对他们毫无意义。此外，这些异常信息包含着一些有价值的信息，它也许能被黑客利用然后侵入你的应用。最后，从应用的角度来说，如果抛出的异常未被处理，那么程序中抛出异常的程序下面的代码就不会被执行，这导致一些资源不能被释放。拿本例来说，若在读取data.text文本文件时抛出异常并且未被处理，那么streamReader,Close()就不会被执行。
向终端用户（end user）显示未处理的异常是不好的做法，有以下两方面的原因：
- 异常信息对用户来说通常是晦涩难懂的，实际意义不大
- 异常中包含一些信息，能被其他人用来hack进你的应用
异常实际上是一个继承自System.Exception类的具体子类。System.Exception基类提供了几个有用的属性，这些属性包含了异常的丰富信息。比如，message属性和Stack Trace属性。
现在，让我们用C#提供的构造来捕捉异常。
try
{
StreamReader streamReader = new StreamReader(@"c:data1.txt");
Console.WriteLine(streamReader.ReadToEnd());
streamReader.Close();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
Console.WriteLine(ex.Source);
Console.WriteLine(ex.TargetSite);
}
现在，通过try...catch我们捕捉到了异常，但是由于我们传给catch的是基类异常Exception，那么，我们仅能使用几个属性，由于我们已经知道抛出的是FileNotFoundException，故我们可以进行改进，将Exception改为FileNotFoundException，这样的话，我们在Catch语句块中处理异常时可以利用FileNotFoundException的更多属性（比如FileName属性）来提供更加有意义的异常处理程序。比如，我们将异常的Message和Stack Trace属性记录到日志文件或者数据库为了调试目的。在这之后还需要向用户显示一个有意义的信息。注意这里基类Exception提供的属性被我们拿来做实际的异常处理（即记录备案，方便稍后调试），在这之后我们可以通过具体异常子类（比如FileNotFoundException）提供的更多属性来向用户显示更加有意义的信息。如下面的代码所示。
try
{
StreamReader streamReader = new StreamReader(@"c:data1.txt");
Console.WriteLine(streamReader.ReadToEnd());
streamReader.Close();
}
catch (FileNotFoundException ex)
{
//这里将异常的详细信息记录到数据库或日志文件
Console.WriteLine("请检查文件{0}是否存在",ex.FileName);
}
现在让我们将上面的代码做一点变化，如下图所示，
try
{
StreamReader streamReader = new StreamReader(@"c:Test_FileData1.txt");
Console.WriteLine(streamReader.ReadToEnd());
streamReader.Close();
}
catch (FileNotFoundException ex)
{
//这里将异常的详细信息记录到数据库或日志文件
Console.WriteLine("请检查文件{0}是否存在",ex.FileName);
}
这里我们添加上了Test_File路径名，但实际上该目录不存在，那么这时就会抛出DirectoryNotFoundException，由于没有对应的处理程序，那么程序就会终止，由于我们在开发中不可能记住所有的抛出的具体异常的类型名，因此，在这里我们可以这样处理，在FileNotFoundException异常的catch块之后添加捕获基类Exception异常的catch块，这样的话，如果有我们预料之外的任何异常都将在最后一个捕获基类Exception异常的catch块中得到处理。这里，需要注意的是所有的捕获具体异常类型的catch块必须位于捕获基类Exception异常的catch块之前，否则C#编译器将报错。这里最后一个捕获基类Exception异常的catch块之所以能捕获任意子类型异常，正是体现了继承的思想：父类型的引用能指向任何子类型的实例对象。
try
{
StreamReader streamReader = new StreamReader(@"c:Test_FileData1.txt");
Console.WriteLine(streamReader.ReadToEnd());
streamReader.Close();
}
catch (FileNotFoundException ex)
{
//这里将异常的详细信息记录到数据库或日志文件
Console.WriteLine("请检查文件{0}是否存在",ex.FileName);
}
catch(Exception ex)
{
Console.WriteLine(ex.Message);
}
让我们来看看为什么需要finally块。上面代码中，如果try块抛出异常，那么streamReader就不能正常关闭，进而造成资源得不到释放。这时候finally块就派上用场了，finally块中的语句无论是否抛出异常均保证得到执行。因此，我们常将一些资源清理的工作放在finally块中。本例中，我们可以将streamReader.Close()放在finally块中。
另外，常有人质疑finally块的作用。他们的理由就是可以将资源清理的工作放在最后一个catch语句块之后，因为无论try块中是否发生异常，最后一个catch块之后的程序代码均会被执行。这种说法是错误的！因为当try块捕获到异常，转到catch块中进行处理时，若在catch块中再次抛出异常且此异常没有设置对应的处理程序，那么程序就会终止，不会执行最后一个catch块之后的任何程序代码。