异常规范

异常增强了API的一致性。如果使用异常，那么报告错误的方式是固顶的，从而保证了API的一致性

想在面向对象框架中统一使用返回值来报告错误是不可能的，在这种情况下，唯一的选择是使用返回值之外的错误报告方法，比如异常

使用异常使得对于开发人员处理错误的位置更加灵活

更容易使错误处理局部化

错误码很容易被忽略，而且通常都被忽略

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

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

异常有助于instumentation

不要返回错误码

要通过抛出异常的方式来报告操作失败

如果一个方法无法完成它的名字对应的任务，那么因该认为这是方法层面的操作失败，这时应该抛出异常

考虑通过调用System.Environment.FailFast(.NET2.0版新特性)来终止进程，而不要抛出异常，如果代码遇到严重问题，已经无法继续安全的执行。

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

考虑抛出异常可能会对性能造成影响

要为所有的异常撰写文档，并把它们作为协定的一部分，前提是这些异常是由于违反了公有成员的协定而抛出。

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

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

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

不要在异常筛选器中抛出异常

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

 

考虑优先使用System名字空间中已有的异常，而不是自己创建新的异常类型

要使用自定的异常类型，如果对错误的处理方式与其他已有的异常有所不同

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

要使用最合理、最具针对性的异常

 

 

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

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

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

避免在异常消息中使用问号和惊叹号

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

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

 

不要在框架的代码中，在捕获具体类型不确定的异常时，把错误吞了

避免在应用程序的代码中，在捕获具体类型不确定的异常时，把错误吞了

不要在为了转移异常而编写的catch代码块中把任何特殊的异常排除在外

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

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

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

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

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

 

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

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

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

 

不要抛出System.Exception或System.SystemException异常

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

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

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

要抛出InvalidOperationException异常，如果对象处于不正确的状态

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

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

要在属性的设置方法中，以value作为隐式值参数的名字

不要让共用API显式地或隐式的抛出NullReferenceException、IndexOutOfRangeException或AccessViolationException异常

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

不要捕获StatckOverflowException异常

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

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

不要显示地抛出ExecutionEngineException异常。

 

避免太深的继承层次

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

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

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

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

public calss SomeException : Exception : ISerializable

{

       public SomeException();

       public SomeException(string message);

       public SomeException(string message,. Exception inner);

 

       //this constructor is needed for serialization

       protected SomeException(SerailizationInfo info, StreamingContext context);

}

 

要通过ToString的重载方法来报告对安全敏感的信息，前提是必须先获得相应的许可，如果无法获得许可，那么应该在返回的字符串中除去对安全敏感消息

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

考虑为异常定义属性，这样能从程序中取得与异常有关的额外信息

 

不要因异常可能对性能造成的负面影响而使用错误码。要提高性能，既可以使用Tester-Doer模式，也可以使用Try-Parse模式

考虑在方法中使用Testor-Doer模式来避免因异常而引起的性能问题，如果该方法在普通的场景中都可能会抛出异常。

考虑在方法中使用Try-Parse模式来避免因异常而引起的性能问题，如果该方法在普通的场景中都可能会抛出异常

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

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