《.NET 设计规范》第 7 章：异常

第 7 章：异常

　　异常与各种面向对象语言集成得非常好。

　　异常增强了 API 的一致性。

　　在用返回值来报告错误时，错误处理的代码与可能会发生错误的代码距离总是很近。

　　更容易使错误处理的带码全局化。

　　错误码很容易被忽略，而且经常会被忽略。

　　异常可以包含丰富的信息来对错误的原因加以描述。

　　异常允许用户定义未处理异常的处理程序。

　　异常可以包含丰富的信息来对错误额原因加以描述。

　　异常允许用户定义未处理异常的处理程序。

　　异常有助于检测。

7.1 抛出异常

　　不要返回错误码。

　　要通过抛出异常的放回来报告操作失败。

　　考虑在代码遇到严重问题且无法继续安全地执行时，通过调用 System.Environment.FailFast 来终止进程，而不要抛出异常。

　　不要在正常的控制流中使用异常，如果能够避免的话。

　　考虑抛出异常可能会对性能造成的影响。对大多数的应用程序来说，每秒抛出 100 个异常很可能会严重地影响性能。　　

　　要为所有的异常撰写文档，并把它们作为契约的一部分 - 如果异常是因为在调用公有成员时违反了它的契约而抛出的（非系统失败）。

　　不要让公有成员根据某个选项来决定是否抛出异常。

　　不要把异常用作公有成员的返回值或输出参数。

　　考虑使用辅助方法来创建异常。

　　不要在异常过滤程序中抛出异常。

　　避免显式地从 finally 代码块中抛出异常。隐式地抛出异常，即在调用其它方法时由其它方法抛出异常，是可以接受的。

　

7.2 为抛出的异常选择合适的类型

　　不要为了通报使用错误而创建新的异常类型。在这种情况下应该抛出框架中已有的异常。

　　考虑为程序错误创建并抛出自定义的异常 - 如果对它的处理方式和对其它异常的处理方式有所不同。否则，应该抛出已有的异常。

　　不要创建新的异常类型 - 如果对该错误的处理和对框架中已有异常的并没有什么不同。在这种情况下应该抛出框架中已有的异常。

　　要创建新的异常类型来传达独一无二的程序错误 - 如果不能通过框架中已有的异常来传达该错误。

　　避免设计出会导致系统失败的 API。如果此类失败可能会发生，那么在发生系统失败时应该调用 Environment.FailFast，而不应该抛出异常。

　　不要仅仅为了拥有自己的异常而创建并使用新的异常。

　　要使用合理的、最具针对性（最底层派生类）的异常。

　　要在抛出异常时为开发人员提供丰富而有意义的错误消息。

　　要确保异常消息的语法正确无误。

　　要确保异常消息中的每个句子都有句号。

　　避免在异常消息这种使用问号和惊叹号。

　　不要在没有得到许可的情况下在异常消息中泄漏安全消息。

　　考虑把组件抛出的异常消息本地化 - 如果想让沐浴为其它语言的开发人员也能使用组件。

　　不要在框架的代码捕获具体类型不确定的异常（比如 System.Exception、System.SystemException，等等）时，把错误吞了。

　　避免在应用程序的代码中，在捕获具体类型不确定的异常（比如 System.Exception、System.SystemException，等等）时，把错误吞了。

　　不要把任何特殊的异常排除在外 - 如果编写 catch 代码块的目的就是为了转移异常。

　　考虑捕获特定类型的异常 - 如果确实理解该异常在具体环境中产生的原因，并能对错误做出适当的反应。

　　不要捕获不应该捕获的异常。通常应该允许异常沿着调用栈向上游传递。

　　要在进行清理工作时使用 try-finally，避免使用 try-catch。对精心编写的异常代码来说，try-finally 的使用频率要比 try-catch 高得多。

　　要在捕获并重新抛出异常时使用空的 throw 语句。这是保持异常调用栈不变的最好方法。

　　不要用无参数的 catch 块来处理不符合 CLS 规范的异常（不是派生自 System.Exception 的异常）。

　　考虑对较低层次抛出的异常进行适当地封装 - 如果较低层次的异常在较高层次的运行环境中没有什么意义。

　　避免捕获并封装具体类型不确定的异常。

　　要在对异常进行封装时为其指定内部异常。

7.3 标准异常类型的使用

　　不要抛出 System.Exception 或 System.SystemExceptio 异常。

　　不要在框架代码中捕获 System.Exception 或 System.SystemException 异常，除非打算重新抛出。

　　避免捕获 System.Exception 或 Systen.SystemException 异常，除非是在顶层的异常处理器中。

　　不要抛出 System.ApplicationException 或从它派生新类。

　　要抛出 InvalidaOperationException 异常 - 如果对象处于不正确的状态。

　　要在用户传入无效参数时抛出 ArgumentException 异常或其子类型。如果可以的话，要尽量使用位于继承层次末尾的异常类型。

　　要在抛出 ArgumentException 异常或其子类时设置 ParamName 属性。

　　要在属性的 setter 中，以 value 作为 value 隐式参数的名字。

　　不要让公共 API 显式地或隐式地抛出 NullReferenceException、AccessViolationException 或 IndexOutOfRangeException 异常。这些异常时专门留给执行引擎来抛出的，大多数情况下它们表示代码存在缺陷。

　　不要显式地抛出 StackOverflowException 异常。应该只有 CLR 才能显式地抛出该异常。

　　不要捕获 StackOverflowException 异常。

　　不要显式地抛出 OutOfMemoryException 异常。应该只有 CLR 才能抛出异常。

　　不要显示地抛出 ComException、ExecutingEngineException 及 SEHException 异常，应该只有 CLR 才能抛出这些异常。

7.4 自定义异常的设计

　　要从 System.Exception 或其它常用的异常基类派生新的异常。

　　避免太深的继承层次。

　　要在命名异常类时使用“Exception”后缀。

　　要使异常可序列化。为了使异常能够在跨应用程序域和跨远程边界时仍能正常使用，这样做是必须的。

　　要为所有的异常（至少）提供下面这些常用的构造函数。

　　要通过 ToString 的一个覆盖方法来报告与安全性有关的消息，前提是必须先获得相应的许可。

　　要把与安全性有关的信息保存在私有的异常状态中，并确保只有可信赖的代码才能得到该信息。

　　考虑为异常定义属性，这样就能从程序中取得除了消息字符串之外与异常有关的额外信息。

　　

7.5 异常与性能

　　不要因异常可能对性能造成负面影响而使用错误码。

　　考虑在成员中使用 Tester-Doer 模式来避免因异常而引起的性能问题 - 如果成员在常用场景中都可能抛出异常。

　　考虑在成员中使用 Try-Parse 模式来避免因异常而引起的性能问题，如果成员在常用代码中都可能会抛出异常。

　　要在实现 Try-Parse 模式时使用“Try”前缀，并用布尔类型作为方法的返回类型。

　　要为每个使用 Try-Parse 模式的方法提供一个会抛出异常的对应成员。