Java异常处理的最佳实践

### Java异常处理的最佳实践 #### 1. 仅在异常情况下使用异常 在编程中，我们有时可能会遇到类似下面这样的代码： ```java // Horrible abuse of exceptions. Don't ever do this! try { int i = 0; while(true) range[i++].climb(); } catch (ArrayIndexOutOfBoundsException e) { } ``` 这段代码的目的是遍历数组元素，但它使用了异常来控制循环的结束。实际上，它等价于下面这种标准的Java数组遍历方式： ```java for (Mountain m : range) m.climb(); ``` 那为什么会有人使用基于异常的循环呢？有人错误地认为，由于虚拟机（VM）会检查所有数组访问的边界，普通的循环终止测试是多余的，应该避免。然而，这种推理存在三个问题： - **性能问题**：异常是为异常情况设计的，JVM实现者没有太大动力让它们像显式测试那样快。 - **优化受限**：将代码放在`try-catch`块中会抑制JVM实现可能进行的某些优化。 - **冗余检查并非必然**：标准的数组遍历方式不一定会导致冗余检查，许多JVM实现会对其进行优化。 实际上，基于异常的循环不仅会使代码的目的模糊，降低性能，而且不能保证正常工作。如果循环中存在错误，使用异常进行流程控制可能会掩盖错误，大大增加调试的难度。 这个原则对API设计也有影响。一个设计良好的API不应迫使客户端在普通控制流中使用异常。对于只能在某些不可预测条件下调用的“状态依赖”方法，通常应该有一个单独的“状态测试”方法，用于指示是否适合调用该状态依赖方法。例如，`Iterator`接口有状态依赖方法`next`和相应的状态测试方法`hasNext`，这使得我们可以使用传统的`for`循环（以及`for-each`循环，其中内部使用了`hasNext`方法）来遍历集合： ```java for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) { Foo foo = i.next(); ... } ``` 如果`Iterator`接口没有`hasNext`方法，客户端将不得不使用下面这种糟糕的代码来遍历集合： ```java // Do not use this hideous code for iteration over a collection! try { Iterator<Foo> i = collection.iterator(); while(true) { Foo foo = i.next(); ... } } catch (NoSuchElementException e) { } ``` 这种基于异常的循环不仅冗长且容易误导，而且性能可能较差，还可能掩盖系统中无关部分的错误。 除了提供单独的状态测试方法，另一种选择是让状态依赖方法在无法执行所需计算时返回一个空的可选值（`Optional`）或一个特殊值（如`null`）。以下是一些选择状态测试方法、可选返回值或特殊返回值的指导原则： - **并发访问或状态易变**：如果对象要在没有外部同步的情况下进行并发访问，或者会受到外部状态转换的影响，必须使用可选返回值或特殊返回值，因为在调用状态测试方法和状态依赖方法之间，对象的状态可能会发生变化。 - **性能考虑**：如果单独的状态测试方法会重复状态依赖方法的工作，出于性能考虑，可能需要使用可选返回值或特殊返回值。 - **其他情况**：在其他条件相同的情况下，状态测试方法略优于特殊返回值。它的可读性稍好，并且更容易检测到错误的使用：如果忘记调用状态测试方法，状态依赖方法将抛出异常，使错误显而易见；如果忘记检查特殊返回值，错误可能会比较隐蔽。对于可选返回值则不存在这个问题。 总之，异常是为异常情况设计的，不要将其用于普通控制流，也不要编写迫使他人这样做的API。下面是一个简单的流程图，展示了异常使用的判断逻辑： ```mermaid graph TD; A[需要控制流] --> B{是否为异常情况}; B -- 是 --> C[使用异常]; B -- 否 --> D[使用标准控制流]; ``` #### 2. 为可恢复条件使用受检异常，为编程错误使用运行时异常 Java提供了三种可抛出对象：受检异常、运行时异常和错误。程序员在何时使用每种可抛出对象时可能会感到困惑。虽然决策并不总是明确的，但有一些通用规则可以提供有力的指导。 决定使用受检异常还是未受检异常的首要规则是：为调用者可以合理预期恢复的条件使用受检异常。通过抛出受检异常，你迫使调用者在`catch`子句中处理异常或将其向外传播。因此，方法声明要抛出的每个受检异常都是向API用户表明，相关条件是调用该方法可能产生的结果。 例如，当尝试使用礼品卡进行购买因资金不足而失败时抛出受检异常，该异常应该提供一个访问器方法来查询短缺的金额，以便调用者将该金额告知购物者。 有两种未受检可抛出对象：运行时异常和错误。它们的行为相同：都不需要，并且通常不应该被捕获。如果程序抛出未受检异常或错误，通常情况下恢复是不可能的，继续执行可能会造成更大的危害。如果程序没有捕获这样的可抛出对象，它将导致当前线程停止，并显示适当的错误消息。 使用运行时异常来指示编程错误。大多数运行时异常表示前置条件违规。例如，数组访问的契约规定，数组索引必须在零到数组长度减一之间（包括零和数组长度减一），`ArrayIndexOutOfBoundsException`表示违反了这个前置条件。 然而，有时很难判断是可恢复条件还是编程错误。例如，资源耗尽可能是由编程错误（如分配了过大的数组）或真正的资源短缺引起的。如果资源耗尽是由临时短缺或临时需求增加导致的，该条件可能是可恢复的。API设计者需要根据具体情况判断某个资源耗尽实例是否可能允许恢复。如果认为条件可能允许恢复，使用受检异常；如果不认为可以恢复，使用运行时异常。如果不确定是否可以恢复，最好使用未受检异常。 Java语言规范虽然没有要求，但有一个强烈的约定，即错误是由JVM用于指示资源不足、不变性失败或其他无法继续执行的条件。鉴于这一约定几乎被普遍接受，最好不要实现任何新的`Error`子类。因此，你实现的所有未受检可抛出对象都应该是`RuntimeException`的子类（直接或间接）。除了`AssertionError`，也不应该抛出`Error`。 此外，虽然可以定义一个不是`Exception`、`RuntimeException`或`Error`子类的可抛出对象，但这样做没有好处，只会让API用户感到困惑，所以不建议这么做。 API设计者常常忘记异常是完整的对象，可以在其上定义任意方法