受检的异常是Java程序设计语言的一项很好的特性。与返回代码不同,它们强迫程序员处理异常的条件,大大增强了可靠性。如果方法抛出一个或者多个受检的异常,调用该方法的代码就必须在一个或者多个catch块中处理这些异常,或者它必须声明它抛出这些异常,并让它们传播出去。无论哪种方法,都给程序员增添了不可忽视的负担。
如果正确地使用API并不能阻止这种异常条件的产生,并且一旦产生异常,使用API的程序员可以立即采取有用的动作,这种负担就被认为是正当的。除非这两个条件都成立,否则更适合于使用未受检的异常。
被一个方法单独抛出的受检异常,会给程序员带来非常高的额外负担。如果这个方法还有其他的受检异常,它被调用的时候一定已经出现在一个try块中,所以这个异常只需要另外一个catch块。如果方法只抛出单个受检的异常,仅仅一个异常就会导致该方法不得不外于try块中。在这些情况下,应该问自己,是否有别的途径来避免使用受检的异常。
“把受检的异常变成未受检的异常”的一种方法是,把这个抛出异常的方法分成两个方法,其中第一个方法返回一个boolean,表明是否应该抛出异常。这种API重构,把下面的调用序列:
//Invocation with checked exception
try {
obj.action(args);
} catch(TheCheckedException e) {
// Handle exceptional condition
}
重构为:
// Invocation with state-testing method and unchecked exception
if (obj.actionPermitted(args)) {
obj.action(args);.
} else {
// Handle exceptional condition
}
这种重构并不总是恰当的,但是,凡是在恰当的地方,它都会使API用起来更加舒服。虽然后者的调用序列没有前者的漂亮,但是这样得到的API更加灵活。如果程序员知道调用将会成功,或者不介意由于调用失败而导致的线程终止,这种重构还允许以下这个更为简单的调用形式:
obj.action(args);
如果你怀疑这个简单的调用序列是否合乎要求,这个API重构就是恰当的。这种重构之后的API在本质上等同于第57条中的“状态测试方法”,并且,同样的告诫依然适用:如果对象将在缺少外部同步的情况下被并发访问,或者可被外界改变状态,这种重构就是不恰当的,因为在actionPermitted和action这两个调用的时间间隔之中,对象的状态有可能会发生变化。如果单独的actionPermitted方法必须重复action方法的工作,出于性能的考虑,这种API重构就不值得去做。