IcanFixIt

Tips
书中的源代码地址:https://github.com/jbloch/effective-java-3e-source-code
注意,书中的有些代码里方法是基于Java 9 API中的,所以JDK 最好下载 JDK 9以上的版本。

Effective Java, Third Edition

70. 对可恢复条件使用已检查异常,对编程错误使用运行时异常

Java提供了三种可抛出异常对象:已检查异常( checked exceptions)、运行时异常(runtime exceptions)和虚拟机错误(errors)。程序员们对什么时候使用每种抛出的异常比较困惑。虽然决策并不总是明确的,但是有一些通用规则可以提供有力的指导。

决定是否使用已检查异常或未检查异常的基本规则是:对于可以合理地预期调用者将从中恢复的条件,使用已检查异常。通过抛出一个已检查的异常,可以强制调用者在catch子句中处理异常,或者将其传播出去。因此,声明要抛出方法的每个已检查异常都有力地向API用户表明,关联的条件是调用该方法的一个可能的结果。

通过向用户提供已检查异常,API设计器提供了从异常条件中恢复的要求。用户可以通过捕获异常并忽略异常来无视这个要求,但这通常不是一个好主意(条目 77)。

有两种未检查的可抛出的异常:运行时异常和虚拟机错误。它们在行为上是一样的:都是可抛出的,通常不应该被捕获。如果程序抛出未检查的异常或错误,通常情况下是无法恢复的,继续执行的话弊大于利。如果程序没有捕捉到这样的可抛出的异常,会导致当前线程挂起或停止,并发出适当的错误消息。

使用运行时异常来指出编程错误。 绝大多数运行时异常表示违反了先决条件(precondition violation)。 违反先决条件的原因仅仅是客户端API无法遵守API规范建立的约定。 例如,数组访问的约定指定数组索引必须介于0和数组长度减去1之间)。 ArrayIndexOutOfBoundsException异常指出违反了此先决条件。

这个建议的一个问题是,你并不总是清楚是在处理可恢复的异常还是编程错误。例如,考虑资源耗尽的情况,这可能是由编程错误(如分配一个不合理的大数组)或真正的资源短缺造成的。如果资源枯竭是由于临时短缺或需求临时增加造成的,这种情况很可能是可以恢复的。对于API设计人员来说,判断给定的资源耗尽实例是否允许恢复是一个问题。如果你认为某个条件可能允许恢复,请使用已检查的异常;如果不能,则使用运行时异常。如果不清楚是否可以恢复,最好使用未检查的异常,原因将在条目 71中讨论。

虽然Java语言规范没有要求,但有一个强烈的约定,即保留错误(errors)以供JVM使用,以指示资源缺陷,不变性失败(invariant failures),以及其他无法继续执行的条件。 鉴于几乎普遍接受这种约定,最好不要实现任何新的Error子类。 因此,实现所有未经检查的可抛出异常应该是RuntimeException的子类(直接或间接子类)。 不仅不应该定义Error子类,而且除了AssertionError之外,也不应该抛出它们。

可以定义一个可抛出的异常,不是Exception、RuntimeException或Error的子类。JLS不直接处理这些可抛出类,而是隐式地指定它们作为普通的检查异常(它们是Exception的子类,但不是RuntimeException)。那么,什么时候应该使用这样的可抛出异常?总之,永远不会。与普通的检查异常相比,它们没有任何好处,只会让API的使用者感到困惑。

API设计者经常忘记异常是也是完全成熟的对象,可以在其上定义任意方法。此类方法的主要用途是提供捕获异常的代码,其中包含有关导致抛出异常的条件的其他信息。 在没有这样的方法的情况下,已知程序员解析异常的字符串表示以发现附加信息。 这是非常糟糕的做法(条目 12)。 可抛出的类很少指定其字符串表示的细节,因此字符串表示可能因实现而异,也可能因发布而异。 因此,解析异常的字符串表示的代码可能是不可移植且脆弱的。

因为检查异常通常表示可恢复的异常条件,所以对它们来说,提供信息的方法来帮助调用者从异常条件中恢复尤为重要。例如,假设当使用礼品卡购物的尝试由于资金不足而失败时,抛出一个已检查的异常。异常应该提供一个访问器方法来查询差额的数量。这会使调用者能够将金额传递给购物者。有关此主题的更多信息,请参见条目 75。

总而言之,为可恢复的异常条件抛出已检查异常,为编程错误抛出未检查异常。当有疑虑不确定时,抛出未检查的异常。不要定义任何既不是已检查异常也不是运行时异常的可抛出异常。提供已检查异常的方法,用来帮助恢复。

相关文章: