当对象抛出异常之后,通常我们期望这个对象仍然保持在一种定义良好的可用状态之中,即使失败是发生在执行某个操作的过程中间。对于受检异常而言,这尤为重要,因为调用者期望能从这种异常中进行恢复。一般而言,失败的方法调用应该使对象保持在被调用之前的状态。具有这种属性的方法被称为具有失败原子性(failure atomic)。
有几种途径可以实现这种效果。第一种就是设计一个不可变的对象,如果对象是不可变的,失败原子性就是显然的。如果一个操作失败了,它可能会阻止创建新的对象,但是永远也不会使已有的对象保持在不一致的状态之中,因为当每个对象被创建之后它就不会再发生改变。
对于可变对象上执行操作的方法,获得失败原子性最常见的方法是,再执行操作之前检查参数的有效性。例如:
public Object pop() {
if (size == 0)
throw new EmptyStackException();
Object result = element[--size];
element[size] = null;
return result;
}
如果取消对初始大小(size)的检查,当这个方法企图从一个空栈中弹出元素时,它仍然会抛出异常。然而,这将会导致size域保持在不一致的状态(负数)之中,从而导致将来对该对象的任何方法调用都会失败。此外,那时,pop方法抛出的ArrayIndexOutofBoundsException异常对于该抽象来说也是不恰当的(详见第73条)。
第三种获得失败原子性的方法是,在对象的一份临时拷贝上执行操作,当操作完成之后再用临时拷贝中的结果代替对象的内容。
最后一种获得失败原子性的方法远远没有那么常用,那就是编写一段恢复代码,由它来拦截操作过程中发生的失败,以及使对象回滚到操作开始之前的状态。这种办法主要用于永久性的(基于磁盘的)数据结构。
虽然一般情况下都希望实现失败原子性,但并非总是可以做到。举个例子,如果两个线程企图在没有适当的同步机制的情况下,并发地修改同一个对象,这个对象就有可能被留在不一致的状态之中。因此,在捕获了ConcurrentModificationException异常之后再假设对象仍然是可用的,这就是不正确的。错误通常是不可恢复的,因此,当方法抛出AssertionError时,不需要努力去保持失败原子性。
总而言之,作为方法规范的一部分,它产生的任何异常都应该让对象保持在调用该方法之前的状态。如果违反这条规则,API文档就应该清楚地指明对象将会处于什么样的状态。遗憾的是,大量现有的API文档都未能做到这一点。