11 C# 第十章 异常

书中关于异常介绍了一些处理原则，还是挺实用的，这里记下来以后可以参考一下。但原则归原则，工作中的实际情况千差万别，有时候要权衡一下，活学活用吧。

异常处理的原则：

只捕捉(处理)能处理的异常。

举例：当程序捕捉到一个异常，这个异常有两种可能性，一是系统级别的，二是和我们要做的业务相关的。
如果要是和我们的业务相关的，比如我们打开一个要操作的目标文件失败了，等等，这个就是我们自己程序
可以处理的，只要有恰当的提示信息和处置方法，就不会引起其他的问题。但是系统级别的异常就是我们
自己的程序无法处理的了，为了安全只能用关闭程序或其他类似的操作，对这种异常还是尽量交给上
一层的程序来处理。

不要隐藏你不能完全处理的异常。

对于异常我们有时候会把它捕捉到，但仅仅是捕捉到，然后就假装什么都没发生过，这可能会导致严重的系统问题。

尽可能少的使用System.Exception

几乎所有的异常都是从System.Exception中派生的，但有时候处理某些System.Exception的最佳方式是不对他们进行处理或者以最快的方式关闭程序。例如：System.OutOfMemoryException 或 System.StackOverflowExcepiton等，这些异常在系统看来是不可恢复的。所以捕捉他们但不重新引发它们会造成系统的崩溃。

避免在调用栈较低的位置报告或记录异常。

有时开发者倾向于一旦异常发生我们就记录并且报告它。但如果程序此时处于调用栈交低的位置时，我们很难完整的获得异常的信息，或者有更全局的处理方式，导致不得不重新再抛出异常，或重复记录了异常的信息。

在一个catch 块中使用throw; 而不是throw<异常对象>语句。

我们可以在catch块中重新引发异常，例如代码：
catch(ArgumentUnllException ex)
{
        throw new ArgumentUnllException;
}
像这样重新引发的异常，系统会将栈追踪的位置重置为新引发的位置，而不是重用原始位置。
所以如不是要引发新类型的异常，或故意隐藏原始的调用栈，就该使用throw;语句。
使相同的调用栈向上传播。
catch(ArgumentUnllException ex)
{
        throw;
}

重新引发不同的异常时要小心。

在一个catch 块内部，假如重新引发了一个不同类型的异常，引起的结果：
1)   重置异常的引发点
2)   隐藏原始的异常
这有时会为我们调试问题带来麻烦。 重新引发不同类型的异常要小心。


重新引发不同异常的情况：

a)   更改异常类型有助于更好的澄清问题。

b)   保护异常信息中保护的一些敏感的私有数据信息

   例如: 一个System.IO.Exception中报告我们程序的配置文件不存在，并且包含了配置文件的路径   "C:\Program File\aa\conf.dat"，这个路径是我们不希望用户看到的，我们可以重新再引发一个新的异常来隐藏它。

c)   异常类型过于具体，以致于调用者不能恰当的处理。