第76条：使失败保持原子性

        当对象抛出异常之后，通常我们期望这个对象仍然保持在一种定义良好的可用状态之中，即使失败是发生在执行某个操作的过程中间。对于受检异常而言，这尤为重要，因为调用者期望能从这种异常中进行恢复。一般而言，失败的方法调用应该使对象保持在被调用之前的状态。具有这种属性的方法被称为具有失败原子性（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文档都未能做到这一点。