第9章 异常

第57条：只针对异常的情况才使用异常

对于“状态测试方法”和“可识别的返回值”这两种做法，有些指导原则可以帮助你在两者之中做出选择。如果对象将在缺少外部同步的情况下被并发访问，

或者可被外界改变状态，使用可被识别的返回值可能是很有必要的，因为在调用“状态测试”方法和调用对应的“状态相关”方法的时间间隔之中，对象的

状态有可能会发生变化。如果单独的“状态测试”方法必须重复“状态相关”方法的工作，从性能的角度考虑，就应该使用可被识别的返回值。如果所有

其他方面都是等同的，那么“状态测试”方法则略优于可被识别的返回值。它提供了更好的可读性，对于使用不当的情形，可能更加易于检测和改正：如果

忘了去调用状态测试方法，状态相关的方法就会抛出异常，使这个Bug变得很明显；如果忘了去检查可识别的返回值，这个Bug就很难会被发现。

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

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

Java程序设计语言提供了三种可抛出结构（throwable）：受检的异常（checked  exception）、运行时异常（run-time exception）和错误（error）。

在决定使用受检的异常或是未受检的异常时，主要的原则是：如果期望调用者能够适当地恢复，对于这种情况就应该使用受检的异常。通过抛出受检的异常，

强迫调用者在一个catch子句中处理该异常，或者将它传播出去。因此，方法中声明要抛出的每个受检的异常，都是对API用户的一种潜在指示：与异常相关联

的条件是调用这个方法的一种可能的结果。

用运行时异常来表明编程错误。大多数的运行时异常都表示前提违例（precondition violation）。所谓前提违例是指API的客户没有遵守API规范建立的约定。

你实现的所有未受检的抛出结构都应该是RuntimeException的子类（直接的或者间接的）。

第59条：避免不必要地使用受检的异常

受检的异常是Java程序设计语言的一项很好的特性。与返回代码不同，它们强迫程序员处理异常的条件，大大增强了可靠性。也就是说，过分使用受检的

异常会使API使用起来非常不方便。如果方法抛出一个或者多个受检的异常，调用该方法的代码就必须在一个或者多个catch块中处理这些异常，或者它

必须声明它抛出这些异常，并让它们传播出去。无论哪种方法，都给程序员增添了不可忽视的负担。

第60条：优先使用标准的异常

最常见的可重用异常：

IllegalArgumentException                非null的参数值不正确

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

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

IndexOutOfBoundsException         下标参数值越界

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

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

第61条：抛出与抽象相对应的异常

更高层的实现应该捕获底层的异常，同时抛出可以按照高层抽象进行解释的异常。这种做法被称为异常转译（exception translation）

尽管异常转译与不加选择地从低层传递异常的做法相比有所改进，但是它也不能被滥用。

如果不能阻止或者处理来自更低层的异常，一般的做法是使用异常转译，除非低层方法碰巧可以保证它抛出的所有异常对高层也合适

才可以将异常从低层传播到高层。异常链对高层和低层都提供了最佳的功能：它允许抛出适当的高层异常，同时又能捕获底层的原因

进行失败分析。

第62条：每个方法抛出的异常都要有文档

始终要单独地声明受检的异常，并且利用Javadoc的@throws标记，准确地记录下抛出每个异常的条件。

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

如果一个类中的许多方法处于同样的原因而抛出同一个异常，在该类的文档注释中对这个异常建立文档，这是可以接受的，而不是为每个方法

单独建立文档。

要为你编写的每个方法所能抛出的每个异常建立文档。对于未受检和受检的异常，以及对于抽象的和具体的方法也都一样。要为每个受检异常

提供单独的throws子句，不要为未受检的异常提供throws子句。如果没有为可以抛出的异常建立文档，其他人就很难或者根本不可能有效地

使用你的类和接口。

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

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

第64条：努力使失败保持原子性

当对象抛出异常之后，通常我们期望这个对象仍然保持在一种定义良好的可用状态之中，即使失败是发生在执行某个操作的过程中间。对于受检的异常

而言，这尤为重要，因为调用者期望能从这种异常中进行恢复。一般而言，失败的方法调用应该使对象保持在被调用之前的状态。具有这种属性的方法

被称为具有失败原子性。

对于在可变对象上执行操作的方法，获得失败原子性最常见的办法是，在执行操作之前检查参数的有效性。这可以使得在对象的状态被修改之前，先

抛出适当的异常。

一种类似的获得失败原子性的办法是，调整计算处理过程的顺序，使得任何可能会失败的计算部分都在对象状态被修改之前发生。如果对参数的检查只有

执行了部分计算之后才能进行，这种办法实际上就是上一种办法的自然扩展。

第三种获得失败原子性的办法远远没有那么常用，做法是编写一段恢复代码（recovery code），由它来拦截操作过程中发生的失败，以及使对象回滚到操作

开始之前的状态上。这种办法主要用于永久性的数据结构。

最后一种获得失败原子性的办法是，在对象的一份临时拷贝上执行操作，当操作完成之后再用临时拷贝中的结果代替对象的内容。如果数据保存在临时的数据

结构中，计算过程会更加迅速，使用这种办法就是件很自然的事。

第65条：不要忽略异常

不管异常代表了可预见的异常条件，还是编程错误，用空的catch块忽略它，将会导致程序在遇到错误的情况下悄然地执行下去。然后，有可能在将来的某个点上，

当程序不能再容忍与错误源明显相关的问题时，它就会失败。正确地处理异常能够彻底挽回失败。只要将异常传播给外界，至少会导致程序迅速地失败，从而

保留了有助于调试该失败条件的信息。