异常以及处理教程

《异常以及处理教程》由会员分享，可在线阅读，更多相关《异常以及处理教程（11页珍藏版）》请在金锄头文库上搜索。

1、异常设计准则2011-8-26 许云剑,异常的引发,异常处理,捕捉和引发标准异常类型,设计自定义异常,异常和性能,1：异常的引发,当某一成员无法成功执行它应执行的操作时，将引发异常。这称为执行故障 。 下列准则可帮助确保在适当时引发异常 不要返回错误代码。异常是报告框架中的错误的主要手段。 通过引发异常来报告执行故障。如果某一成员无法按预期方式成功执行，则应将这种情况视为一个执行故障并引发一个异常。 如果代码遇到继续执行则不安全的情况，应考虑通过调用 System.Environment.FailFast(System.String)（.NET Framework 2.0 中的一种功能）来终止

2、进程，而不是引发异常。 尽可能不对正常控制流使用异常。除了系统故障及可能导致争用状态的操作之外，框架设计人员还应设计一些 API 以便用户可以编写不引发异常的代码。例如，可以提供一种在调用成员之前检查前提条件的方法，以便用户可以编写不引发异常的代码。 考虑引发异常的性能影响。 记录公共可调用的成员因成员协定冲突（而不是系统故障）而引发的所有异常，并将这些异常视为协定的一部分。包含在协定中的异常不应从一个版本更改到下一个版本。 不要包含将异常作为返回值或输出参数返回的公共成员。 考虑使用异常生成器方法。从不同的位置引发同一异常会经常发生。为了避免代码膨胀，请使用帮助器方法创建异常并初始化其属性。

3、 避免从 finally 块中显式引发异常。可以接受因调用引发异常的方法而隐式引发的异常。,1.1：选择要引发的正确异常类型,考虑引发 System 命名空间中的现有异常，而不是创建自定义异常类型 如果错误状态可以通过不同于现有任何其他异常的方法以编程方式进行处理，则要创建并引发自定义异常。否则，引发一个现有异常 不要只是为了您所在的团队获得异常而创建和引发新异常。 引发适当的最具体（派生程度最大）的异常。例如，如果某方法收到一个 null（在 Visual Basic 中为 Nothing）参数，则该方法应引发 System.ArgumentNullException，而不是引发该异常的基类

4、型 System.ArgumentException。,1.2：包装异常,如果低层异常在高层操作的上下文中没有意义，则考虑在更适当的异常中包装在低层引发的特定异常 避免捕捉和包装非特定异常：这种处理会隐藏错误，因此需要避免 包装异常时务必要指定内部异常。,1.3：错误信息设计,在引发异常时为开发人员提供丰富且有意义的消息文本。消息应说明导致异常的原因并清楚描述避免该异常需采取的操作。 确保异常消息的语法正确。顶级异常处理程序可以向应用程序终端用户显示异常消息。 确保消息文本的每个句子都是以句号（“。”）结尾。这样，向用户显示异常消息的代码不必处理开发人员忘记最后面的句号的情况，这种处理相当麻烦

5、而且代价很大 避免在异常消息中使用问号（“?”）和感叹号（“!”）。 不要在不要求相应权限的异常消息中透露安全敏感信息。 如果希望使用不同语言的开发人员使用您的组件，则应考虑对您的组件所引发的异常消息进行本地化。,2：异常处理,不要在框架代码中捕捉非特定异常（如 System.Exception、System.SystemException 等）以至忽略错误。 避免在应用程序代码中捕捉非特定异常（如 System.Exception、System.SystemException 等）以至忽略错误。某些情况下，可以在应用程序中忽略错误，但这种情况极少。 如果捕捉异常是为了传输异常，则不要排除任何

6、特殊异常 如果了解特定异常在给定上下文中引发的条件，请考虑捕捉这些异常。 不要过多使用 catch。通常应允许异常在调用堆栈中往上传播。 使用 try-finally 并避免将 try-catch 用于清理代码。在书写规范的异常代码中，try-finally 比 try-catch 使用得更多。 捕捉并再次引发异常时，首选使用空引发。这是保留异常调用堆栈的最佳方式。 不要使用无参数 catch 块来处理不符合 CLS 的异常（不是从 System.Exception 派生的异常）。支持不是从 Exception 派生的异常的语言可以处理这些不符合 CLS 的异常。,3：捕捉和引发标准异常类型,

7、Exception 和 SystemException 不要引发 System.Exception 或 System.SystemException。 不要在框架代码中捕捉 System.Exception 或 System.SystemException，除非打算再次引发。 避免捕捉 System.Exception 或 System.SystemException，在顶级异常处理程序中除外。 ApplicationException：不要引发 System.ApplicationException 或从该异常进行派生。 InvalidOperationException：如果处于不适当的状

8、态，则引发 System.InvalidOperationException 异常。如果没有向属性集或方法调用提供适当的对象当前状态，则应引发 System.InvalidOperationException。例如，向已打开用于读取的 System.IO.FileStream 写入时，应引发 System.InvalidOperationException 异常。 ArgumentException、ArgumentNullException 和 ArgumentOutOfRangeException：如果向成员传递了错误的参数，则引发 System.ArgumentException 或其子

9、类型之一。如果适用，首选派生程度最高的异常类型。 在引发 System.ArgumentException 或其派生类型之一时，设置 System.ArgumentException.ParamName 属性。此属性存储导致引发异常的参数的名称。注意，使用其中一个构造函数重载可以设置该属性。 使用属性 setter 的隐式值参数的名称的值。 不要允许公开可调用的 API 显式或隐式引发 System.NullReferenceException、System.AccessViolationException、System.InvalidCastException 或 System.IndexO

10、utOfRangeException。进行参数检查以避免引发这些异常。引发这些异常会公开方法的实现细节，这些细节可能会随时间发生更改。 StackOverflowException 不要显式引发 System.StackOverflowException。此异常只应由公共语言运行库 (CLR) 显式引发。 不要捕捉 System.StackOverflowException。 OutOfMemoryException：不要显式引发 System.OutOfMemoryException。此异常只应由 CLR 基础结构引发。 ComException 和 SEHException：不要显式引发

11、System.Runtime.InteropServices.COMException 或 System.Runtime.InteropServices.SEHException。这些异常只应由 CLR 基础结构引发。 不要显式捕捉 System.Runtime.InteropServices.SEHException。 ExecutionEngineException：不要显式引发 System.ExecutionEngineException。,4：设计自定义异常(1),避免使用深的异常层次结构。 一定要从 System.Exception 或其他常见基本异常之一派生异常。 异常类名称一定

12、要以后缀 Exception 结尾。 应使异常可序列化。异常必须可序列化才能跨越应用程序域和远程处理边界正确工作。 一定要在所有异常上都提供（至少是这样）下列常见构造函数。确保参数的名称和类型与在下面的代码示例中使用的那些相同。,4：设计自定义异常(2),一定要只在要求适合的权限后，才通过 System.Object.ToString 的重写报告安全敏感信息。如果权限要求失败，则返回一个不包括安全敏感信息的字符串。 一定要以私有异常状态存储有用的安全敏感信息。请确保只有受信任的代码才能获取该信息。 考虑提供异常属性，以便可以以编程方式访问除消息字符串之外与异常相关的额外信息。,5：异常和性能,不要由于担心异常可能会对性能造成不良影响而使用错误代码。 对于可能在常见方案中引发异常的成员，可以考虑使用 Tester-Doer 模式来避免与异常相关的性能问题。 为每个使用 TryParse 模式的成员提供一个引发异常的成员。,