异常增强了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模式的方法提供一个会抛出异常的对应成员。
2447
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
