zoukankan      html  css  js  c++  java
  • 异常处理

    面的准则有助于确保库正确处理异常。

    不要在框架代码中捕捉非特定异常(如 System.Exception、System.SystemException 等)以至忽略错误。

    如果捕捉异常是为了再次引发或传输给其他线程,则可以捕捉这些异常。下面的代码示例演示的异常处理是不正确的。

       1: public class BadExceptionHandlingExample1
       2: {
       3:     public void DoWork()
       4:     {
       5:         // Do some work that might throw exceptions.
       6:     }
       7:     public void MethodWithBadHandler()
       8:     {
       9:         try 
      10:         {
      11:             DoWork();
      12:         }
      13:         catch (Exception e)
      14:         {
      15:             // Swallow the exception and continue
      16:             // executing.
      17:         }
      18:     }
      19: }

    避免在应用程序代码中捕捉非特定异常(如 System.Exception、System.SystemException 等)以至忽略错误。某些情况下,可以在应用程序中忽略错误,但这种情况极少。

    应用程序不应该忽略异常,否则可能导致意外状态或可利用状态。如果不能预知所有可能的异常原因,也不能确保恶意代码不能利用产生的应用程序状态,则应该允许应用程序终止,而不是忽略异常。

    如果捕捉异常是为了传输异常,则不要排除任何特殊异常。

    只捕捉能够合法处理的异常,而不要在 catch 子句中创建特殊异常的列表。在非特定异常处理程序中,不能处理的异常不应视为特殊处理的特殊情况。下面的代码示例演示对以再次引发为目的特殊异常进行的不正确测试。

       1: public class BadExceptionHandlingExample2
       2: {
       3:     public void DoWork()
       4:     {
       5:         // Do some work that might throw exceptions.
       6:     }
       7:     public void MethodWithBadHandler()
       8:     {
       9:         try 
      10:         {
      11:             DoWork();
      12:         }
      13:         catch (Exception e)
      14:         {
      15:             if (e is StackOverflowException ||
      16:                 e is OutOfMemoryException)
      17:                 throw;
      18:             // Handle exception and continue 
      19:             // executing.
      20:         }
      21:     }
      22: }
      23:  

    果了解特定异常在给定上下文中引发的条件,请考虑捕捉这些异常。

    应该只捕捉可以从中恢复的异常。例如,试图打开不存在的文件而导致的 FileNotFoundException 可以由应用程序处理,因为应用程序可以将问题传达给用户,并允许用户指定其他文件名或创建该文件。如果打开文件的请求会生成 ExecutionEngineException,则不应该处理该请求,因为没有任何把握可以了解该异常的基础原因,应用程序也无法确保继续执行是安全的。

    不要过多使用 catch。通常应允许异常在调用堆栈中往上传播。

    捕捉无法合法处理的异常会隐藏关键的调试信息。

    使用 try-finally 并避免将 try-catch 用于清理代码。在书写规范的异常代码中,try-finally 比 try-catch 使用得更多。

    使用 catch 子句是为了允许处理异常(例如,通过纪录非致命错误)。无论是否引发了异常,使用 finally 子句即可执行清理代码。如果分配了昂贵或有限的资源(如数据库连接或流),则应将释放这些资源的代码放置在 finally 块中。

    捕捉并再次引发异常时,首选使用空引发。这是保留异常调用堆栈的最佳方式。

    下面的代码示例演示一个可引发异常的方法。此方法在后面示例中引用。

       1: public void DoWork(Object anObject)
       2: {
       3:     // Do some work that might throw exceptions.
       4:     if (anObject == null)
       5:     {
       6:         throw new ArgumentNullException("anObject", 
       7:             "Specify a non-null argument.");
       8:     }
       9:     // Do work with o.
      10: }

    下面的代码示例演示捕捉一个异常,并在再次引发该异常时对它进行错误的指定。这会使堆栈跟踪指向再次引发作为错误位置,而不是指向 DoWork 方法

       1: public void MethodWithBadCatch(Object anObject)
       2: {
       3:     try 
       4:     {
       5:         DoWork(anObject);
       6:     }
       7:     catch (ArgumentNullException e)
       8:     {
       9:        System.Diagnostics.Debug.Write(e.Message);
      10:        // This is wrong.
      11:        throw e; 
      12:        // Should be this:
      13:        // throw;
      14:     }
      15: }

    不要使用无参数 catch 块来处理不符合 CLS 的异常(不是从 System.Exception 派生的异常)。支持不是从 Exception 派生的异常的语言可以处理这些不符合 CLS 的异常。
     


    作者:GangWang
    出处:http://www.cnblogs.com/GnagWang/
    本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

     
  • 相关阅读:
    [原] KVM 虚拟化原理探究(6)— 块设备IO虚拟化
    [原] KVM 虚拟化原理探究(5)— 网络IO虚拟化
    [原] KVM 虚拟化原理探究(4)— 内存虚拟化
    [原] KVM 虚拟化原理探究(3)— CPU 虚拟化
    [原] KVM 虚拟化原理探究(2)— QEMU启动过程
    [原] KVM虚拟机网络闪断分析
    [原] KVM 环境下MySQL性能对比
    [源]云计算技术堆栈系列——鸟瞰
    [原] 利用 OVS 建立 VxLAN 虚拟网络实验
    [原] Cgroup CPU, Blkio 测试
  • 原文地址:https://www.cnblogs.com/GnagWang/p/1701877.html
Copyright © 2011-2022 走看看