标签：environ exce 方式 engine out ati test try 执行
异常与各种面向对象语言集成得非常好。
异常增强了 API 的一致性。
在用返回值来报告错误时，错误处理的代码与可能会发生错误的代码距离总是很近。
更容易使错误处理的带码全局化。
错误码很容易被忽略，而且经常会被忽略。
异常可以包含丰富的信息来对错误的原因加以描述。
异常允许用户定义未处理异常的处理程序。
异常可以包含丰富的信息来对错误额原因加以描述。
异常允许用户定义未处理异常的处理程序。
异常有助于检测。
不要返回错误码。
要通过抛出异常的放回来报告操作失败。
考虑在代码遇到严重问题且无法继续安全地执行时，通过调用 System.Environment.FailFast 来终止进程，而不要抛出异常。
不要在正常的控制流中使用异常，如果能够避免的话。
考虑抛出异常可能会对性能造成的影响。对大多数的应用程序来说，每秒抛出 100 个异常很可能会严重地影响性能。
要为所有的异常撰写文档，并把它们作为契约的一部分 - 如果异常是因为在调用公有成员时违反了它的契约而抛出的（非系统失败）。
不要让公有成员根据某个选项来决定是否抛出异常。
不要把异常用作公有成员的返回值或输出参数。
考虑使用辅助方法来创建异常。
不要在异常过滤程序中抛出异常。
避免显式地从 finally 代码块中抛出异常。隐式地抛出异常，即在调用其它方法时由其它方法抛出异常，是可以接受的。
不要为了通报使用错误而创建新的异常类型。在这种情况下应该抛出框架中已有的异常。
考虑为程序错误创建并抛出自定义的异常 - 如果对它的处理方式和对其它异常的处理方式有所不同。否则，应该抛出已有的异常。
不要创建新的异常类型 - 如果对该错误的处理和对框架中已有异常的并没有什么不同。在这种情况下应该抛出框架中已有的异常。
要创建新的异常类型来传达独一无二的程序错误 - 如果不能通过框架中已有的异常来传达该错误。
避免设计出会导致系统失败的 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 的异常）。
考虑对较低层次抛出的异常进行适当地封装 - 如果较低层次的异常在较高层次的运行环境中没有什么意义。
避免捕获并封装具体类型不确定的异常。
要在对异常进行封装时为其指定内部异常。
不要抛出 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 才能抛出这些异常。
要从 System.Exception 或其它常用的异常基类派生新的异常。
避免太深的继承层次。
要在命名异常类时使用“Exception”后缀。
要使异常可序列化。为了使异常能够在跨应用程序域和跨远程边界时仍能正常使用，这样做是必须的。
要为所有的异常（至少）提供下面这些常用的构造函数。
要通过 ToString 的一个覆盖方法来报告与安全性有关的消息，前提是必须先获得相应的许可。
要把与安全性有关的信息保存在私有的异常状态中，并确保只有可信赖的代码才能得到该信息。
考虑为异常定义属性，这样就能从程序中取得除了消息字符串之外与异常有关的额外信息。
不要因异常可能对性能造成负面影响而使用错误码。
考虑在成员中使用 Tester-Doer 模式来避免因异常而引起的性能问题 - 如果成员在常用场景中都可能抛出异常。
考虑在成员中使用 Try-Parse 模式来避免因异常而引起的性能问题，如果成员在常用代码中都可能会抛出异常。
要在实现 Try-Parse 模式时使用“Try”前缀，并用布尔类型作为方法的返回类型。
要为每个使用 Try-Parse 模式的方法提供一个会抛出异常的对应成员。
标签：environ exce 方式 engine out ati test try 执行
原文地址：http://www.cnblogs.com/liqingwen/p/7341998.html
