第9章 异常

57、只针对异常的情况才使用异常

       其他情况用异常不正确的原因：（1）异常机制的设计初衷是用于不正常的情形，很少会有JVM试图对它进行优化；（2）把代码放在try-catch块中反而阻止了现代JVM实现本来可能要执行的 特定优化；（说到底就是异常阻止了JVM的优化···）

       设计良好的API不应该强迫它的客户端为了正常的控制流而使用异常。

       总之，异常是为了在异常情况下使用而设计的，不要将它们用于普通的控制流，也不要编写迫使他们这么做到API。

58、对可恢复的情况使用受检异常，对编程错误使用运行时异常

       java程序设计语言提供了三种可抛出结构：受检的异常（checked exception）、运行时异常（run-timeexception）和错误（error）。后两者是未受检异常。

59、避免不必要地使用受检的异常

       被一个方法单独抛出的受检异常，会给程序员带来非常高的额外负担。

60、优先使用标准的异常

       常用异常：

       IllegalArgumentException 非null的参数值不正确

       IllegalStateException 对象方法调用而言，对象状态不合适

       NullPointerException 在禁止使用null的情况下参数值为null

       IndexOutOfBoundsException 下标参数值越界

       ConcurrentModificationException 在禁止并发修改的情况下，检测到对象的并发修改

       UnsupportedOperationException 对象不支持用户请求的方法

       一定要确保抛出异常的条件与该异常的文档中描述的条件一致。

61、抛出与抽象相对应的异常

       异常转译：更高层的实现应该捕获低层的异常，同时抛出可以按照高层抽象进行解释的异常。

       异常链：低层的异常被传到高层的异常，高层的异常提供访问方法来捕获低层的异常。如低层抛出new 高层异常(低层异常);将低层异常传递给高层异常的构造。

       如果不能阻止或者处理来自更低层的异常，一般的做法是使用异常转译，除非低层方法碰巧可以保证它抛出的所有异常对高层也合适才可以将异常从低层传播到高层。（否则，不但使人困惑，而且污染了更高层的API）

       异常链对高层和低层异常都提供了最佳的功能：它允许抛出适当的高层异常，同时又能捕获低层的原因进行失败分析。

62、每个方法抛出的异常都要有文档

       始终要单独地声明受检的异常，并且利用Javadoc的@throws标记，准确地记录下抛出每个异常的条件。永远不要声明一个方法“throws Exception”，或更糟糕的是声明它“throwsThrowable”，他们实际上掩盖了该方法在同样的执行环境下可能抛出的任何其他异常。

       使用Javadoc的@throws标签记录它下面的一个方法可能抛出的每个未受检异常，但是不要使用throws关键字将未受检的异常包含在方法声明中。

63、在细节消息中包含能捕获失败的信息

       为了捕获失败，异常的细节信息应该包含所有“对该异常有贡献”的参数和域的值。

       可以尝试的方法：在异常的构造器（以参数形式传入）而不是字符串细节消息中引入这些信息。有了这些信息，只要把它们放到消息描述中，就可以自动产生细节消息。但java平台类库并没有广泛地使用这种做法。

64、努力使失败保持原子性

       失败的方法调用应该使对象保持在被调用之前的状态，具有这种属性的方法被称为具有失败原子性。

       （1）对于在可变对象上执行操作的方法，获得失败原子性最常见的办法是，在抛出操作之前检查参数的有效性，这可以使得在对象的状态被修改之前，先抛出适当的异常。综合可以这么说：调整计算处理过程的顺序，使得任何可能会失败的计算部分都在对象状态被修改之前发生。（2）可以编写恢复代码，这方法很少用；（3）在对象的一份临时拷贝上执行操作，当操作完成之后再用临时拷贝中的结果代替对象的内容。

65、不要忽略异常

       尽量不要使catch块为空，至少应该包含一条说明，解释为什么可以忽略这个异常。