常以及处理教程.pptVIP

异常设计准则 2011-8-26 许云剑 * 异常的引发 异常处理 捕捉和引发标准异常类型 设计自定义异常 异常和性能 * 1：异常的引发 当某一成员无法成功执行它应执行的操作时，将引发异常。这称为执行故障 。 下列准则可帮助确保在适当时引发异常 不要返回错误代码。异常是报告框架中的错误的主要手段。 通过引发异常来报告执行故障。如果某一成员无法按预期方式成功执行，则应将这种情况视为一个执行故障并引发一个异常。 如果代码遇到继续执行则不安全的情况，应考虑通过调用 System.Environment.FailFast(System.String)（.NET Framework 2.0 中的一种功能）来终止进程，而不是引发异常。 尽可能不对正常控制流使用异常。除了系统故障及可能导致争用状态的操作之外，框架设计人员还应设计一些 API 以便用户可以编写不引发异常的代码。例如，可以提供一种在调用成员之前检查前提条件的方法，以便用户可以编写不引发异常的代码。 考虑引发异常的性能影响。 记录公共可调用的成员因成员协定冲突（而不是系统故障）而引发的所有异常，并将这些异常视为协定的一部分。包含在协定中的异常不应从一个版本更改到下一个版本。 不要包含将异常作为返回值或输出参数返回的公共成员。 考虑使用异常生成器方法。从不同的位置引发同一异常会经常发生。为了避免代码膨胀，请使用帮助器方法创建异常并初始化其属性。 避免从 finally 块中显式引发异常。可以接受因调用引发异常的方法而隐式引发的异常。 * 1.1：选择要引发的正确异常类型 考虑引发 System 命名空间中的现有异常，而不是创建自定义异常类型 如果错误状态可以通过不同于现有任何其他异常的方法以编程方式进行处理，则要创建并引发自定义异常。否则，引发一个现有异常 不要只是为了您所在的团队获得异常而创建和引发新异常。 引发适当的最具体（派生程度最大）的异常。例如，如果某方法收到一个 null（在 Visual Basic 中为 Nothing）参数，则该方法应引发 System.ArgumentNullException，而不是引发该异常的基类型 System.ArgumentException。 * 1.2：包装异常 如果低层异常在高层操作的上下文中没有意义，则考虑在更适当的异常中包装在低层引发的特定异常 避免捕捉和包装非特定异常：这种处理会隐藏错误，因此需要避免 包装异常时务必要指定内部异常。 * 1.3：错误信息设计 在引发异常时为开发人员提供丰富且有意义的消息文本。消息应说明导致异常的原因并清楚描述避免该异常需采取的操作。 确保异常消息的语法正确。顶级异常处理程序可以向应用程序终端用户显示异常消息。 确保消息文本的每个句子都是以句号（“。”）结尾。这样，向用户显示异常消息的代码不必处理开发人员忘记最后面的句号的情况，这种处理相当麻烦而且代价很大 避免在异常消息中使用问号（“?”）和感叹号（“!”）。 不要在不要求相应权限的异常消息中透露安全敏感信息。 如果希望使用不同语言的开发人员使用您的组件，则应考虑对您的组件所引发的异常消息进行本地化。 * 2：异常处理 不要在框架代码中捕捉非特定异常（如 System.Exception、System.SystemException 等）以至忽略错误。 避免在应用程序代码中捕捉非特定异常（如 System.Exception、System.SystemException 等）以至忽略错误。某些情况下，可以在应用程序中忽略错误，但这种情况极少。 如果捕捉异常是为了传输异常，则不要排除任何特殊异常 如果了解特定异常在给定上下文中引发的条件，请考虑捕捉这些异常。 不要过多使用 catch。通常应允许异常在调用堆栈中往上传播。 使用 try-finally 并避免将 try-catch 用于清理代码。在书写规范的异常代码中，try-finally 比 try-catch 使用得更多。 捕捉并再次引发异常时，首选使用空引发。这是保留异常调用堆栈的最佳方式。 不要使用无参数 catch 块来处理不符合 CLS 的异常（不是从 System.Exception 派生的异常）。支持不是从 Exception 派生的异常的语言可以处理这些不符合 CLS 的异常。 * 3：捕捉和引发标准异常类型 Exception 和 SystemException 不要引发 System.Exception 或 System.SystemException。 不要在框架代码中捕捉 System.Exception 或 System.SystemException，除非打算再次引发。