《Robust java》学习-第二章异常处理

异常处理的提倡的原则：

1）尽可能的处理异常

      要尽可能的处理异常，如果条件确实不允许，无法在自己的代码中完成处理，就考虑声明异常。如果人为避免在代码中处理异常，仅作声明，则是一种错误和依赖的实践。

2）具体问题具体解决

       异常的部分优点在于能为不同类型的问题提供不同的处理操作。有效异常处理的关键是识别特定故障场景，并开发解决此场景的特定相应行为。为了充分利用异常处理能力，需要为特定类型的问题构建特定的处理器块。

3）记录下可能会影响程序运行的异常

       至少要采取一些永久的方式，记录下可能影响应用程序操作的异常。理想情况下，当然是在第一时间解决引发异常的基本问题。不过，无论采用哪种处理操作，一般总应记录下潜在的关键问题。别看这个操作很简单，但它可以帮助您用很少的时间来跟踪应用程序中复杂问题的起因。

4）根据情况将异常转化为业务上下文

       若要通知一个应用程序特有的问题，有必要将应用程序转换为不同形式。若用业务特定状态表示异常，则代码更易维护。从某种意义上讲，无论何时将异常传到不同上下文（即另一技术层），都应将异常转换为对新上下文有意义的形式。

异常处理忌讳的原则：

1）不要忽略异常

1 try{ 2 Class.forName("business.domain.Customer"); 3 } 4 catch (ClassNotFoundException exc){}

      咋一看，觉得对于程序的运转没有带来任何问题，但是这其实是很危险的，程序可能会运行出一些怪异的行为，例如，应用程序设置的一个值不见了， 或 GUI 失效。若问题严重，则应用程序可能会出现重大问题。并且由于没有记录，完全排查不了是哪里出了问题。

2）不要使用覆盖式的异常处理块

     另一个危险的处理是覆盖式处理器（blanket handler）。该代码的基本结构如下：

1 try{ 2 // … 3 } 4 catch(Exception e){ 5 // … 6 }

      使用覆盖式异常处理块有两个前提之一：

      1. 代码中只有一类问题。

       这可能正确，但即便如此，也不应使用覆盖式异常处理，捕获更具体的异常形式有利物弊。

      2. 单个恢复操作始终适用。

         这几乎绝对错误。几乎没有哪个方法能放之四海而皆准，能应对出现的任何问题。

         分析下这样编写代码将发生的情况。只要方法不断抛出预期的异常集，则一切正常。但是，如果抛出了未预料到的异常，则无法看到要采取的操作。当覆盖式处理器对新异常类执行千篇一律的任务时，只能间接看到异常的处理结果。如果代码没有打印或记录语句，则根本看不到结果。

更糟糕的是，当代码发生变化时，覆盖式处理器将继续作用于所有新异常类型，并以相同方式处理所有类型。

3）不要将特定的异常转化为更通用的异常

将特定的异常转换为更通用异常时一种错误做法。一般而言，这将取消异常起初抛出时产生的上下文，在将异常传到系统的其他位置时，将更难处理。见下例：

1 try{ 2 // Error-prone code 3 } 4 catch(IOException e){ 5 String msg = "If you didn ’ t have a problem before,you do now!"; 6 throw new Exception(msg); 7 }

因为没有原始异常的信息，所以处理器块无法确定问题的起因，也不知道如何更正问题。

4）不要处理能够避免的异常

       对于有些异常类型，实际上根本不必处理。在上篇文章中提到的RuntimeException这类异常属于此类范畴。详细信息可看第一章内容。