总结十条.NET异常处理建议

.net中从始至终要紧记异常处理的策略：抛出具体的一个异常，而不是只抛出exception类型的异常，这样能方便我们捕获对应类型的异常。我们在编写代码时要注意考虑到应用程序最差的情况；显示有好的信息，并提供适当的管理员联系信息。

1、不要抛出“new exception()”

请别这样做。exception是一个非常抽象的异常类，捕获这类异常通常会产生很多负面影响。通常情况下应该定义我们自己的异常类，并且需要区分系统抛出的异常和我们自己抛出的异常。

2、不要将重要的异常信息存储在message属性中

异常都封装在类中。当你需要返回异常信息时，请将信息存储在一些单独的属性中（而不要放在message属性中），否则人们很难从message属性中解析出他们需要的信息。比如当你仅仅需要纠正一下拼写错误，如果你将错误信息和其它提示内容一起以string的形式写在了message属性中，那么别人该怎样简单地获取他们要的错误信息呢？你很难想象到他们要做多少努力。

3、每个线程要包含一个try/catch块

一般异常处理都放在了程序中一个比较集中的地方。每个线程都需要有一个try/catch块，否则你会漏掉某些异常从而出现难以理解的问题。当一个程序开启了多个线程去处理后台任务时，通常你会创建一个类型来存储各个线程执行的结果。这时候请不要忘记了为类型增加一个字段来存储每个线程可能发生的异常，否则的话，主线程不会知道其他线程的异常情况。在一些“即发即忘”的场合，你可能需要将主线程中的异常处理逻辑复制一份到你的子线程中去。

4、捕获异常后要记录下来

不管你的程序是使用何种方式记录日志——log4net、eif、event log、tracelisteners或者文本文件等，这些都不重要。重要的是：当你遇到异常后，应该在某个地方将它记录在日志中。但是请仅仅记录一次，否则的话，你最后会得到一个非常大的日志文件，包含了许多重复信息。

5、不要只记录exception.message的值，还需要记录exception.tostring()

当我们谈到记录日志时，不要忘了我们应该记录exception.tostring()的值，而不是exception.message。因为exception.tostring()包含了“堆栈跟踪”信息，内部异常信息以及message。通常这些信息非常重要，而如果你只记录exception.message的话，你只可能看到类似“对象引用未指向堆中实例”这样的提示。

6、要捕获具体的异常

如果你要捕获异常，请尽可能的捕获具体异常（而非exception）。好的代码只能捕获它知道该怎么处理的异常 

7、不要忘记使用using

仅仅调用对象的dispose()方法是不够的。即使异常发生时，using关键字也能够防止资源泄漏 

8、不要使用特殊返回值去表示方法中发生的异常

1）、直接抛出异常更快，因为使用特殊的返回值表示异常时，我们每次调用完方法时，都需要去检查返回结果，并且这至少要多占用一个寄存器。降低代码运行速度。
2）、特殊返回值能，并且很可能被忽略
3）、特殊返回值不能包含堆栈跟踪信息，不能返回异常的详细信息
4）、很多时候，不存在一个特殊值去表示方法中发生的异常，比如，除数为零的情况 

9、不要将“抛出异常”作为函数执行结果的一种

这是一个非常糟糕的设计。代码中包含太多的try/catch块会使代码难以理解，恰当的设计完全可以满足一个方法返回各种不同的执行结果，如果你确实需要通过抛出异常来表示方法的执行结果，那只能说明你这个方法做了太多事情，必须进行拆分 

10、可以使用“抛出异常”的方式去着重说明不能被忽略的错误

例如我为我的一个产品开发了一个用来登录的api（login），如果用户登录失败，或者用户并没有调用login方法，那么他们调用其他方法时都会失败。我在设计login方法的时候这样做的：如果用户登录失败，它会抛出一个异常，而并不是简单的返回false。正因为这样，调用者（用户）才不会忽略（他还没登录）这个事实。

ps: .net异常处理的四要素

1.一个表示异常详细信息的类。
2.一个像调用者引发异常类实例的成员。
3.调用者的一段调用异常成员的的模块。
4.调用者的一段处理或捕获将要发生异常的代码块。