八、异常

1. 只针对异常的情况才使用异常

异常机制的设计初衷是用于不正常的情形，它只能用于异常的情况，永远不应该用于正常的控制流。
设计良好的API不应该强迫它的客户端为了正常的控制流而使用异常。如果类具有“状态相关”的方法，这个类往往也应该有个单独的“状态测试”方法，指示是否可以调用这个状态相关的方法。例如，Iterator接口有一个“状态相关”的next()和相应的状态测试方法hasNext()。这使得利用for循环对集合进行迭代的标准模式成为可能：

for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) {
    Foo foo = i.next();
    ...
}

如果Iterator缺少hasNext()，客户端将被迫改用下面的做法：

try {
    Iterator<Foo> i = collection.iterator();
    while(true) {
        Foo foo = i.next();
        ...
    }
} catch (NoSuchElementException e) {
}

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

JDK异常体系结构如下图所示（只列出部分常见异常）：

Java语言提供了三种可抛出结构（throwable）：

受检的异常（checked exception)
运行时异常（run-time exception）
错误（error）

异常的使用情形：

期望调用者能够适当地恢复，使用受检的异常
程序错误，使用运行时异常

方法中声明要抛出的受检的异常，都是API对用户的一种潜在的提示；与异常相关联的条件是调用这个方法的一种可能的结果。

运行时异常和错误都是未受检的可抛出结构，在行为上两者是等同的，它们都不需要也不应该被捕获。如果程序抛出未受检的异常或错误，往往就属于不可恢复的情形，继续执行下去有害无益，此时系统应做的就是及时终止，并及时提示错误信息。
按照惯例，错误往往被JVM保留用于表示资源不足、约束失败，或者其他使程序无法继续执行的条件。因此最好不要再实现任何新的Error子类，实现的所有未受检的抛出结构都应该是RuntimeException直接或间接的子类。

异常也是个完全意义上的对象，可以在它上面定义任意的方法。这些方法的主要用途是为捕获异常的代码提供额外的信息，特别是关于引发这个异常条件的信息。
受检的异常往往指明了可恢复的条件，对于这样的异常，提供一些辅助方法尤其重要，通过这些方法，调用者可以获得一些有助于恢复的信息。

3. 避免不必要的使用受检的异常

受检异常强迫程序员处理异常的条件，虽然大大增强了可靠性，但过分使用受检的异常会使API使用起来非常不方便。
如果正确地使用API并不能阻止这种异常条件的产生，并且一旦产生异常，使用API的程序员可以立即采取有用的动作，就可认为这种受检异常是必要的，否则，更适合使用未受检异常。
把受检的异常变成未受检的异常的一种做法是：把这个抛出异常的方法分成两个方法，其中第一个方法返回一个boolean，表明是否应该抛出异常：

重构前：

try {
    obj.action(args);
} catch (TheCheckedException e) {
    ...  // handle exception condition
}

重构后：

if (obj.actionPermitted(args)) {
    obj.action(args);
} else {
    ...  // handle exception condion
}

这种重构并不总是恰当的，但凡是在恰当的地方，它都会使API用起来更加舒服，也更加灵活。

4. 优先使用标准的异常

重用现有的异常是很有好处的：

它使API更加易于学习和使用，因为它与习惯用法是一致的；
对于用到这些API的程序而言，可读性会更好，因为它们不会出现很多程序员不熟悉的异常；
异常类越少，意味着内存印迹就越小，装载这些类的时间开销也越少。

常用的异常如下：

5. 抛出与抽象相对应的异常

如果方法抛出的异常与它所执行的任务没有明显的联系，这种情形将会使人不知所措。当方法传递由低层抽象抛出的异常时，往往会发生这种情况。除了使人感到困惑外，这也让实现细节污染了更高层的API。如果高层的实现在后续的发行版本中发生了变化，它所抛出的异常也可能会跟着发生变化，从而潜在地破坏现有的客户端程序。
为避免上述问题，更高层的实现应该捕获底层的异常，同时抛出可以按照高层抽象进行解释的异常。这种做法被称为异常转译。

try {
    ...
} catch (LowerLevelException e) {
    throw new HigherLevelException(...);
}

如JDK源码中AbstractSequentialList类，它是List接口的一个骨架实现类，按照List<E>接口中get方法的规范，需要对其进行异常转译：

public E get(int index) {
    ListIterator<E> i = listIterator(index);
    try {
        return i.next();
    } catch (NoSuchElementException e) {
        throw new IndexOutOfBoundsException("Index: " + index);
    }
}

异常链是一种特殊的异常转译形式，如果低层的异常对于调试导致高层异常的问题非常有帮助，就应该使低层的异常传到高层的异常，高层的异常提供访问方法来获得低层的异常：

try {
    ...
} catch (LowerLevelException cause) {
    throw new HightLevelException(cause);
}

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

6. 每个文档抛出的异常都要有文档

描述一个方法所抛出的异常，是正确使用这个方法时所需文档的重要组成部分，仔细地为每个方法抛出的异常建立文档是特别重要的。

始终要单独地声明受检的异常，并且利用Javadoc的@throws标记，准确地记录下抛出的每个异常的条件。如果一个方法可能抛出多个异常类，则不要使用“快捷方式”声明它会抛出这些异常的某个超类。永远不要声明一个方法“throws Exception”，或者更糟糕的是声明“throws Throwable”。
使用Javadoc的@throws标签记录方法可能抛出的每个未受检异常，但是不要使用throws关键字将未受检的异常包含在方法的声明中。对使用API的程序员来讲，面对受检异常和未受检异常，他们的责任是不同的，要能清晰区分。

7. 在细节消息中包含能捕获失败的信息

打印异常信息是为了便于分析失败原因的，这些信息中应该包含有利于分析的细节内容。例如IndexOutOfBoundsException异常的细节消息应该包含下界、上界、没有落在界内的下标值。
与用户层级的错误消息不同，异常的字符串表示法主要是让程序员用来分析失败原因，信息的内容比可理解性重要的多。异常信息包含大量的描述信息往往没有什么意义。
Throwable提供了一些接口供获得相应的异常信息：

8. 努力使失败保持原子性

当对象抛出异常后，通常我们期望这个对象仍能保持在一种定义良好的可用状态中，因为调用者期望能从这种异常中进行恢复。一般而言，失败的方法调用应该使对象保持在被调用之前的状态。具有这种属性的方法被称为具有失败原子性。

简而言之，方法执行可以失败，但不能破坏对象的状态。

想要获得失败原子性，通常有四种方法：
（1）设计一个不可变的对象
（2）在执行操作之前检查参数的有效性 即在对象被破坏之前，先抛出异常。

//如果不进行检查，从一个empty stack pop元素会破坏对象状态
public Object pop() {
    if (size == 0) {
        throw new EmptyStackException();
    }
    Object result = elements[--size];
    elements[size] = null;
    return result;
}

（3）编写一段恢复代码
由恢复代码来拦截操作过程中发生的失败，并使对象回滚到操作开始之前的状态上。这种办法主要用于永久性的（基于磁盘的）数据结构。
（4）在对象的一份临时拷贝上执行操作
先在对象拷贝数据上进行操作，再用临时拷贝中的结果代替对象的内容。如Collections.sort()：

    default void sort(Comparator<? super E> c) {
        Object[] a = this.toArray();
        Arrays.sort(a, (Comparator) c);
        ListIterator<E> i = this.listIterator();
        for (Object e : a) {
            i.next();
            i.set((E) e);
        }
    }

9. 不要忽略异常

声明一个方法可能抛出某个异常的时候，等同于在试图提醒某些可能会发生的一些事情，不应忽略它。

try {
    ...
} catch (SomeException e) {
}

空的catch块会使异常达不到应有的目的，它会使对象和系统处于一种不确定的状态，出现问题时，也不易追查错误源。

Fighting_初心

发布了51 篇原创文章 · 获赞 53 · 访问量 2万+

私信关注

Effective Java（八）