.NET异常处理

              很早就想写这篇文章了，但是由于各种事情耽误，所以一直没有下笔，今天有点时间，下定决心写下来吧。

              熟悉C++的人肯定都知道，C++采用的是错误代码的方式来返回错误信息，从系统API到普通应用程序都采用这种方式。这种方式的缺点很明显：返回的代码必须要查阅对应的说明才能知道是什么意思，而且为了展示不同的错误，需要写很长的判断语句，而且每次调用函数时，都要判断其返回值，才能知道是否出错，是否要继续下去。

              在.NET中为了解决这个问题，引入了一种新的异常机制。在这个机制之下，所有的函数都返回void值（除了部分逻辑判断的函数），在没有错误发生的时候，函数正常执行，在有错误发生时，函数会抛出一个特定的异常，从而中断函数，进入异常处理模块。这个机制的好处在于：不必再关心函数是否执行成功，把关注的更多的放到程序本身的业务逻辑上，当有错误发生时，程序会自动进入异常模块，此时只要集中处理好异常模块逻辑就行了。

              这种机制是.NET从上到下都彻底贯彻的一种机制，所以在写.NET程序时，建议同样使用这种机制。一般应遵循以下几点（这几点只是个人根据实际情况总结出来，肯定不能概括所有情况）：

              （1）所有的函数都应该使用void返回值，除了一些逻辑判断的函数。

              （2）所有函数在处理之前都要对参数的有效性进行检查，参数不合法，则抛出异常。

              （3）抛出异常对系统性能有影响，为了尽量少的引发异常，在使用函数之前，需要对传递给函数的参数的合法性进行检查。

              第二条和第三条和结合在一起的。.NET中抛出异常是有一定的性能影响的，所以应该尽可能的避免异常的抛出，因此在使用函数之前，需要对函数实参进行合法性校验，在传递前就过滤不合法的参数。而在函数内部对传入的参数进行检查也是必要的，因为函数的编写者和调用者可能不是同一个人，编写者无法确保每次传入的参数都有效，所以必须进行校验。这样无论调用者是否对实参进行校验，函数都不会出现无法预料的错误。

              （4）在系统的任何位置，都不要捕获不能处理的异常。不能处理的异常应该层层传递，直到表现层。这里不能处理的意思是，捕获这个异常，无法通过某种手段恢复异常。这种异常应该让它抛到表现层，由表现层进行统一的处理。

判断数据库是否连接函数，在这个函数中，需要捕获数据库打开异常，捕获后，返回false，从而通知上层，数据库无法连接，这个异常就必须处理，而不能上抛。

数据库底层插入数据函数，这个函数中，如果插入动作异常，这个异常可以捕获，也可以不捕获，但是一般建议不捕获。

              （5）不要再使用输出参数来传递错误这种表达方式。一旦使用这种方式，就必须判断函数是否执行成功，这会影响程序本身的逻辑处理结构。

              （6）在表现层（winform和web），应该捕获全局的异常，对异常进行统一的展示处理和日志记录，这对用户体验很有帮助。

              （7）在三层架构中，异常在哪一层进行处理没有什么固定的说法。只是要求不能处理的异常，坚决不捕获，不管在那一层。