第61条:抛出与抽象相对应的异常
如果方法抛出的异常与它所执行的任务没有明显的联系,这种情形物会使人不知所措。当方法传递由低层抽象抛出的异常时,往往会发生这种情况。除了使人感到困惑之外,这也让实现细节污染了更高层的API。如果高层的实现在后续的发行版本中发生了变化,它所抛出的异常也可能会跟着发生变化,从而潜在地破坏现有的客户端程序。
为了避免这个问题,更高层的实现应该捕获低层的异常,同时抛出可以按照高层抽象进行解释的异常。这种做法被称为异常转译(exceptiontranslation)。
try{
//Use lower-level abstraction to do our bidding
...
}cache(LowerLevelException e){
throw new HigherLevelException(...);
}
一种特殊的异常转译形式称为异常链(exceptionchaining),如果低层的异常对于调试导致髙层异常的问题非常有帮助,使用异常链就很合适。低层的异常(原因)被传到髙层的异常,髙层的异常提供访问方法(Thmwable.getCause)来获得低层的异常。髙层异常的构造器将原因传到支持链(chaining-aware)的超级构造器,因此它最终将被传给Throwable的其中一个运行异常链的构造器。
大多数标准的异常都有支持链的构造器。对于没有支持链的异常,可以利用Thmwable的initCause方法设置原因。异常链不仅让你可以通过程序(用getCause)访问原因,它还可以将原因的堆栈轨迹集成到更髙层的异常中。
尽管异常转译与不加选择地从低层传递异常的做法相比有所改进,但是它也不能被滥用。最好做法是,在调用低层方法之前确保它们会成功执行,从而避免它们抛出异常。有时候,可以在给低层传递参数之前,检査更高层方法的参数的有效性,从而避免低层方法抛出异常。
如果无法避免低层异常,次选方案是,让更髙层来悄悄地绕开这些异常,从而将高层方法的调用者与低层的问题隔离开来。
总而言之,如果不能阻止或者处理来自更低层的异常,一般的做法是使用异常转译,除非低层方法碰巧可以保证它抛出的所有异常对髙层也合适才可以将异常从低层传播到高居。异常链对髙层和低层异常都提供了最佳的功能:它允许抛出适当的髙层异常,同时又能捕获底层的原因进行失败分析(见第63条)。