11异常处理技巧.ppt

选择要抛出的正确异常类型 下列设计准则可确保正确地使用现有异常，并在适当的时候创建对库有价值的新异常。 考虑引发 System 命名空间中的现有异常，而不是创建自定义异常类型。 如果错误状态可以通过不同于现有任何其他异常的方法以编程方式进行处理，则要创建并抛出自定义异常。否则，抛出一个现有异常。 不要只是为了获得异常而创建和抛出新异常。抛出适当的最具体（派生程度最大）的异常。例如，如果某方法收到一个 null（在 Visual Basic 中为 Nothing）参数，则该方法应引发 System.ArgumentNullException，而不是引发该异常的基类型 System.ArgumentException。 选择要抛出的正确异常类型 5.2 异常处理 下面的准则有助于确保库正确处理异常。 不要通过在框架代码或程序中捕捉非特定异常（如 System.Exception、System.SystemException 等）来处理错误。 如果捕捉异常是为了再次引发或传输给其他线程，则可以捕捉这些异常。 下面的代码示例演示的异常处理是不正确的。 public class BadExceptionHandlingExample1 {public void DoWork(){ // Do some work that might throw exceptions. }public void MethodWithBadHandler(){try{ DoWork(); }catch (Exception e){// Handle the exception and continue executing.}} } 5.2 异常处理 如果捕捉异常是为了传输异常，则不要排除任何特殊异常。 只捕捉能够合法处理的异常，而不要在 catch 子句中创建特殊异常的列表。 在非特定异常处理程序中，不能处理的异常不应视为特殊处理的特殊情况。 下面的代码示例演示对以再次引发为目的特殊异常进行的不正确测试。 5.2 异常处理 public class BadExceptionHandlingExample2 { public void DoWork(){ // Do some work that might throw exceptions. }public void MethodWithBadHandler(){ try{ DoWork(); }catch (Exception e){ if (e is StackOverflowException ||e is OutOfMemoryException)throw;// Handle the exception and continue executing.}} } 5.2 异常处理 如果了解特定异常在给定上下文中引发的条件，请考虑捕捉这些异常。 应该只捕捉可以从中恢复的异常。 例如，尝试打开不存在的文件而导致的 FileNotFoundException 可以由应用程序处理，因为应用程序可以将问题传达给用户，并允许用户指定其他文件名或创建该文件。 如打开文件的请求会生成 ExecutionEngineException，则不应该处理该请求，因为没有任何把握可以了解该异常的基础原因，应用程序也无法确保继续执行是安全的。 不要过多使用 catch。通常应允许异常在调用堆栈中往上传播。 捕捉无法合法处理的异常会隐藏关键的调试信息。 5.2 异常处理 使用 try-finally 并避免将 try-catch 用于清理代码。 书写规范的异常代码中，try-finally 比 try-catch 更为常用 使用 catch 子句是为了允许处理异常（例如，通过纪录非致命错误） 无论是否抛出了异常，使用 finally 子句即可执行清理代码 如果分配了昂贵或有限的资源（如数据库连接或流），则应将释放这些资源的代码放置在 finally 块中。 捕捉并再次抛出异常时，优先使用空抛出。这是保留异常调用堆栈的最佳方式。 不要使用无参数 catch 块来处理不符合 CLS 的异常（不是从 System.Exception 派生的异常）。 5.2 异常处理 5.3捕捉和抛出标准异常类型 下面的准则介绍 .NET Framework 所提供的某些最常用异常的最佳做法。 Exception 和 SystemException 不要抛出 System.Exception 或 System.SystemException 不要在框架代码中捕捉 System.Exception 或 System.SystemException，除非打算再次抛出。 避