46， 显示释放资源，需要实现IDisposable接口。
最好按照微软建议的Dispose模式实现。实现了IDisposable接口后，在Using代码块中，垃圾会得到自动清理。
47， 即使提供了显示的释放方法，也应该在终结器中提供隐式实现。
因为我们不能保证用户会主动去调用这个释放方法，但我们要保证在垃圾回收时，这些资源能得到清理。
48， Dispose方法应该允许被多次调用。
我们可以创建一个变量disposed来标明对象是否被释放了。
49， 在Dispose模式中应提供一个受保护的虚方法。
因为这个类可能被其子类重写，这时我们需要调用父类的Dispose方法。
50， 在Dispose模式中区别对待托管资源和非托管资源。
Dispose(true)是释放所有的托管和非托管资源，是用户主动调用的。Dispose(false)，是垃圾回收器调用的，只能释放非托管资源，因为垃圾回收器的调用顺序是没有保障的，如果这时去释放托管资源，该托管资源可能已经被释放了，从而引发异常。
51， 拥有本机资源或包含可释放字段的类型应该实现Dispose模式。
52， 及时释放资源。
垃圾回收是根据一定的策略来执行的，不再使用的资源要及时释放，不要等到垃圾回收。
53， 必要时应将对象的引用赋值为null。
但要注意一点，对局部变量或函数的参数赋值为null没有太大的意义，因为这些变量会在函数结束时交给垃圾回收器处理，对象变量不再持有对对象的引用。
54， 为无用字段标注不可序列化。
原因可以是以下几种：节约了空间；反序列化后字段没有意义了，如Windows的句柄；业务上的原因不允许被序列化，如密码；字段本身对应的类型不可序列化，这会抛出SerializationException异常。在类型上使用Serializable特性可以将整个类型标识为可序列化，如果部分字段不需要序列化，可以在该字段上应用NonSerialized特性。属性事实上是方法，所以是不能序列化的，自动属性也是如此。另外，要标识事件为不可序列化，需要用field: NonSerialized语法。
55， 利用定制特性减少反序列化的字段。
OnDeSerializedAttribute，应用于方法时会在对象被反序列化后调用，我们可以在这里对没有序列化的字段进行必要的重建。相似的特性还有OnDeSerializingAttribute，OnSerializedAttribute，OnSerializingAttribute。
56， 继承ISerializable接口实现更灵活的序列化过程。
上面提到的几个特性如果不能完全满足我们的要求，可以考虑实现这个接口。有了这个接口，上面应用的特性会被忽略掉。与这个接口相关的两个方法是：ISerializable.GetObjectData，用于序列化对象。protected 类名(SerializationInfo info,StreamingContext context)，添加这个受保护的构造函数用于反序列化。注意，这个方法需要我们手动添加，编译器检查不到，否则不能反序列化，你可以认为这是一种约定。
57， 实现ISerializable的子类应负责父类的序列化。
如果父类实现了ISerializable接口，我们调用base.GetObjectData就可以了；如果没有实现，则需要对父类的每个字段单独进行序列化。
58， 用抛出异常来取代错误返回码。
错误返回码会导致判断分支增加，给调用者带来麻烦，应充分利用.net的异常处理机制来简化代码。
59， 不要在不恰当的场合引发异常。
对于调用WindowsAPI或第三方DLL只能返回错误码的情况，可以考虑抛出自己的异常。代码存在资源泄漏，资源不可用等可以抛出异常。在捕获异常时，需要包装更有用的信息，可以抛出异常。正常的业务流程不应使用异常来处理，例如可控范围内的输入输出。
60， 重新抛出异常时使用InnerException。
将内部异常放置到打包异常里，以供外部程序了解到异常发生的真正原因。
61， 避免在finally块中写无效代码。
如果catch块中有return语句，return 语句是优先于finally块的，也就是如果return返回了变量的值，finally块再修改了这个变量的值，返回结果不会受到影响。当然返回引用的情况除外，因为两个引用指向的是同一个对象。编译器为我们新增加了一个变量用于保存Return处的值，在finally块结束后再返回这个值。另外，对于CSE(Corrupted State Exceptions)异常，在.net 4.0以后CLR不会捕获了，也就是如果程序抛出如AccessViolationException的异常，catch块和finally块代码不会被执行。注意，如果我们主动在托管代码中抛出的new AccessViolationException()是会被捕获的，CLR会检查异常的来源。要改变这种默认的行为，有以下几种方法。1）在调用的方法上添加[System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions]特性。2）改变工程属性的.net版本为3.5或更早，再进行编译。即使这个程序运行在.net4.0的环境中，也会捕获CES异常。3）修改Config文件的配置，在Configuration/runtime下添加这个节点：<runtime><legacyCorruptedStateExceptionsPolicy enabled="true"/></runtime>。后面两种修改方法都是对整个工程生效的。
62， 避免无故的嵌套异常。
嵌套异常会使代码变得臃肿，除非我们要恢复一些状态，否则不应该每个函数都去try catch，这会给调用者带来麻烦，同时也会隐藏掉异常出错的真正原因，不利于排错。我认为内部函数如何仅仅是为了写日志，应该让最外层函数统一处理，内部函数不要捕获异常，如果非要捕获，也要用throw，而不能用throw e，后者会造成堆栈信息的丢失。
63， 避免吃掉异常。
如果我们不知道如何处理异常，就应该往上抛出，交给上层代码来处理。
64， 为循环添加Tester-Doer模式，而不是添加try-catch。
在大量失败的测试中使用try-catch会大大损害性能。可以添加条件判断（如IF等）来避免这种情况。
65， 总是捕获未处理的异常。
未捕获的异常，可以通过System.AppDomain.CurrentDomain.UnhandledException捕获到。Winform中还有一个Application.ThreadException用于捕获UI线程异常。WPF中是Dispatcher类的DispatcherUnhandledException，并且需要设定e.Handed=true;否则会继续引发System.AppDomain.CurrentDomain.UnhandledException异常。
66， 正确捕获多线程中的异常。
多线程中的异常不会主动传递到UI线程中，如果未捕获就会传递到System.AppDomain.CurrentDomain.UnhandledException这里。我们可以将线程中的异常通过代理的方式传递到UI线程中，this.BeginInvoke((Action)delegate { throw ex; });这样可以对未处理的异常进行统一的处理。
67， 慎用自定义异常。
通常自定义异常的理由是：1）方便调试，通过自定义的异常，可以准确知道代码所发生的事情。2）逻辑包装，将多种异常包装成一种异常，方便调用者编码。3）引入新的异常类。
68， 从System.Exception或其他常见的基本异常中派生异常。
注意，自定义异常如需实现序列化，要继承ISerilizable接口，将自定义字段序列化后调用父类的序列化方法GetObjectData。
69， 使用finally避免资源泄漏。
Finally块的特性使我们可以将释放资源的操作放在这里，因为即便出现异常，finally也会被执行。
70， 避免在调用栈较低的位置记录异常。
并不是所有的异常都需要被记录到日志，一类情况是异常发生的场景需要被记录，还有一类是未捕获的异常。为了避免异常被重复记录，应该在项目的初期就约定异常日志记录的规则。