当对某个对象操作时抛出异常之后,通常我们期望这个对象仍然保持在一种定义良好的可用状态之中。因为调用者对象期望能从这种异常中进行恢复。一般而言,失败的对象操作方法应该使对象保持在被操作之前的状态。具有这种属性的方法称为具有失败原子性。
失败原子性实现方法:
1.设计一个不可变对象。对象不可变,那么对象创建出来就不能被修改了,也不需要维护。
2.在执行操作之前检查参数的有效性。在对象状态被修改之前,先抛出异常。考虑Stack.pop方法:
public Object pop(){
if(size == 0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null;//Eliminate obsolete reference
return result;
}
如果取消对初始大小(size)的检查,当这个方法企图从一个空栈中弹出元素时,它仍然会抛出异常。然而,这将会导致size域保持在不一致的状态(负数)中,从而导致将来对该对象的任何方法调用都会失败。此外,那时候pop方法抛出的异常也不适于抽象。
3.调整计算处理的过程,使得任何可能会失败的计算部分都在对象状态被修改之前发生。
4.编写恢复代码,由其拦截操作过程中发生的失败,以及使对象回滚到操作开始之前的状态上。这样做并不提倡,因为错误代码编写遇到复杂的场景会很繁琐。这种办法主要用于永久性的(基于磁盘的(disk-based))数据结构。
5.在对象的一份临时拷贝上执行操作,操作完成后,再使用临时拷贝的的结果代替对象的内容。也就是备份操作。如果数据保存在临时的数据结构中,计算过程会更加迅速,使用这种办法是件很自然的事。例如,Collections.sort在执行排序之前,首先把它的输入列表转到一个数组中,以便降低在排序的内循环中访问元素所需要的开销。这是出于性能考虑的做法,但是,它增加了一项优势:即使排序失败,它也能保证输入列表保持原样。
虽然一般情况下都希望实现失败原子性,但并非总是可以做到。例如,如果两个线程企图在没有适当的同步机制的情况下,并发地修改同一个对象,这个对象就有可能被留在不一致的状态之中。因此,在捕获了ConcurrentModificationException异常之后再假设对象仍然是可用的,这就是不正确的。错误(相对于异常)通常是不可恢复的,当方法抛出错误时,它们不需要努力保持失败原子性。
即使在可以实现失败原子性的场合,它也并不总是人们所期望的。对于某些操作,它会显著地增加开销或者复杂性。但一旦意识到这个问题,实现失败原子性往往轻松自如。
一般而言,作为方法规范的一部分,产生的任何异常都应该让对象保持在该方法调用之前的状态。如果违反这条规则,API文档就应该清楚地指明对象将会处于什么样的状态。遗憾的是,大量现有的API文档都未能做到这一点。