八、异常
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块会使异常达不到应有的目的,它会使对象和系统处于一种不确定的状态,出现问题时,也不易追查错误源。