Effective Java学习(异常)之——避免不必要的使用受检的异常_JAVA_编程开发_程序员俱乐部

? ? ? ?受检异常是java程序语言设计的一项很好的特性。与返回代码不同，他们强迫程序员处理异常的条件，大大增强了可靠性。也就是说，过份的使用受检异常会使API使用起来非常不方便。如果方法抛出一个或者多个受检异常，调用该方法的代码就必须再一个或者多个catch块中处理这些异常，或者他必须声明他抛出这些异常，并让他们传播出去。无论哪种方法，都给程序员增添了不可忽略的负担。

?

? ? ? ?如果正确的使用API并不能阻止这种异常条件的产生，并且一旦产生异常，使用API的程序员可以立即采取有用的动作，这种负担就被认为是正当的。除非这两个条件都成立，否则更适合于使用未受检的异常。作为一个“石蕊”测试，你可以试着问自己：程序员将如何处理该异常。下面做法是最好的吗？

class="java" name="code">}catch(TheCheckedException e){
          throw new AssertionError();
}

?下面这种做法如何？

}catch(TheCheckedException e){
          e.printStackTrace();
          System.exit(1);
}

? ? ? ?如果使用API的程序员无法做的比这更好，那么未受检的异常可能更为合适。这种例子就是CloneNotSupportedException。他就是Object,clone抛出来的，而Object.clone应该只是在实现了 Cloneable的对象上才可以被调用。在实践中catch块几乎总是具有要付出努力，还使程序更为复杂。

?

? ? ? ?被一个方法单独抛出的受检异常，会给程序员带来非常高的额外负担。如果这个方法还有其他的受检异常，他被调用的时候一定已经出现再一个try块中，所以这个异常只需要另外一个catch块。如果方法抛出单个受检异常仅仅一个异常就会导致该方法不得不外与try块中，在这些情况下，应该问问自己，是否有别的路径来避免使用受检异常。

?

? ? ? “把受检异常变成未受检异常”的一种方法是，把这个抛出异常的方法分成两个方法，其中一个方法返回一个boolean，表明是否应该抛出异常。这种API重构，把下面的调用序列：

try{
      obj.action(args);
}catch(TheCheckException e){
      
}

?重构为：

if(obj.actionPermitted(args)){
       obj.action(args);
}catch(TheCheckException e ){
       
}

? ? ? 这种重构并不总是恰当的，但是，凡是在恰当的地方，他都会使API用起来更加舒服，虽然后者的调用序列没有前者漂亮，但是这样得到的API更加灵活。如果程序员知道调用将会成功，或者不介意由于调用失败而导致的线程终止，这种重构还允许以下更为简单的调用形式：

obj.action(args);

? ? ? ?如果你怀疑这个简单的调用序列是否符合要求，这个API重构可能就是恰当的，。这种重构之后的API在本质上等同于异常的“状态测试方法“，并且，同样的告诫依然适用：如果对象将在缺少外部同步的情况下被并发访问，或者可被外界改变状态，这种重构就是不恰当的，因为在actionPermitted和action这两个调用的时间间隔之中，对象的状态有可能会发生变化，如果单独的actionPermitted方法必须重复action方法工作，处于性能的考虑，这种API重构就不值得去做。