7.1 抛出异常
操作失败就是成员不能完成应该完成的任务（成员的名字所暗示的任务）。
不要返回错误码
要通过抛出异常的方式来报告操作失败
考虑用过调用System.Environment.FailFast来终止进程，而不要抛出异常，如果代码遇到了严重问题，已经无法继续安全地执行。
不要将正常的控制流中使用异常，如果能够避免的话
考虑抛出异常可能会对性能造成的影响
要为所有的异常撰写文档，并把它们作为协定的一部分，前提是这些异常时由于违反了公有成员的协定而抛出的。
不要让公有成员根据某个选项来决定是否抛出异常
不要把异常用作公有成员的返回值或输出参数
考虑使用辅助方法来创建异常
不要在异常筛选器（exception filter）中抛出异常
避免显示地从finally代码块中抛出异常。隐私地抛出异常，即在调用其他方法时由其他方法抛出异常，是可以接受的。
7.2 为抛出的异常选择合适的类型
考虑优先使用System名字空间中已有的异常，而不是自己创建新的异常类型
要使用自己定义的异常类型，如果对错误的处理方式与其他已有的异常有所不同。否则的话，应该使用已有的异常。
不要仅仅为了拥有自己的异常而创建并使用新的异常
要使用最合理、最具针对性的异常
7.2.1 错误消息的设计
要在抛出异常时为开发而你又提供丰富而有意义的错误消息
要确保异常消息的语法正确无误
要确保异常消息中的每个句子都有句号
避免在异常消息中使用问号和惊叹号
不要在没有得到许可的情况下载异常消息中泄漏安全信息
考虑把组件抛出的异常消息本地化，比如希望组件为所不同语言的开发人员所使用
7.2.2 异常处理
不要在框架的代码中，在捕获具体类型不确定的异常（比如 System.Exception、System.SystemException等等）时，把错误吞了（让程序继续运行）
避免在应用程序的代码中，在捕获具体类型不确定的异常(比如System.Exception、System.SystemException等等)时，把错误吞了。
不要在为了转移异常而编写的cathc代码快中把任何特殊的异常排除在外
考虑捕获特定类型的异常，如果理解该异常在具体环境产生的原因，并能对错误做出适当的反应
不要捕获不应该捕获的异常。通常应该允许异常沿着调用栈向上传递
要在进行清理工作时使用try-finally，避免使用try-cathc。对精心编写的异常代码来说，try-finally的使用频率有比try-catch高的多
应该用catch代码来从错误中恢复，而用finally代码块来进行清理。
要在捕获并重新抛出异常时使用空的throw语句。这是保持调用栈的最好方法。
不要用无参数的catch块来处理不符合CLS规范的异常(不是派生自System.Exception的异常)
7.2.3 对异常进行封装
考虑对较低层次抛出的异常进行适当的封装，如果较低层次的异常在较高层次的运行环境中没有什么意义。
避免捕获并封装具体类型不确定的异常。
要在对异常进行封装时为其指定内部异常
7.3 标准异常类型的使用
不要抛出SystemException或System.SystemException异常
不要在框架代码中捕获System.Exception或System.SystemException异常，触发打算重新抛出
避免捕获System.Exception或System.SystemException异常，除非是在顶层的异常处理器中
不要抛出System.ApplicationException或从它派生新类
要抛出InvalidOperationException异常，如果对象处于不正确的状态
要抛出ArgumentException异常或其子类，如果传入的是无效参数。要尽可能地使用位于继承层次末尾的类型
要在抛出ArgumentException异常或其子类时设置ParamName属性
要在属性的设置方法中，以value作为隐式值参数的名字
不要让公有API显式或隐式地抛出NullReferenceException、AccessViolationException或IndexOutOfRangeException异常。
不要显式地抛出StackOverflowException异常。应该只用CLR才能显式地抛出该异常。
不要捕获StackOverflowException异常
不要显式抛出OutOfMemoryException异常，应该只用CLR才能抛出该异常
不要显示地抛出InteropException、ComException及SEHException异常。应该只用CLR才能抛出这些异常。
不要显示地捕获SEHException异常。
不要显示地抛出ExceptionEngineException异常
7.4 自定义异常的设计
避免太深的继承层次
要从System.Exception后其他常用的异常基类派生新的异常类
要在命名异常类事业"Exception"后缀
要使异常可序列化。为了使异常能够在跨应该程序域和跨远程编辑时仍能正常工作，这样做事必须的
7. 5 异常和性能