约 9 分钟5 张卡

Java 异常

Java 异常用于表达方法执行失败，并沿调用链传播失败原因。本文从异常分类和捕获规则入手，再说明在哪一层处理失败。随后介绍资源关闭，以及 finally 和多个异常共同出现时的执行结果。

1. 面试核心

先记住这几条，再读正文

异常分类。 Error 和 RuntimeException 及其子类属于非受检异常。卡 · 异常体系
受检要求。 编译器要求受检异常被捕获或声明，异常能否恢复则取决于具体调用场景。
捕获与转换。 当前层有恢复或转换策略时才捕获异常，包装异常时通过 cause 保留原始失败原因。卡 · 抛出、声明与捕获
资源关闭顺序。 try-with-resources 按资源声明的逆序关闭资源。卡 · try-with-resources 与资源关闭
多个失败的保留。 try 主体与资源关闭同时失败时，主体异常向外传播，关闭异常进入它的 suppressed 列表。

2. 异常体系

Java 中可以抛出的对象都属于 Throwable 体系。先看继承关系，再判断编译器是否要求调用方处理异常：

Throwable
├── Error
└── Exception
    ├── RuntimeException
    └── 其他受检异常

Error 包含虚拟机、链接及严重资源错误，例如 OutOfMemoryError。这类问题需要针对具体原因决定如何终止或恢复，统一捕获全部 Error 容易掩盖严重故障。

Exception 是另一条常见分支，其中包含 RuntimeException。RuntimeException、Error 及其子类属于非受检异常。其余异常类受编译器检查，包括 Throwable 自身。

void load(Path path) throws IOException { // 受检异常需要声明或捕获
    Files.readString(path);
}

int parsePort(String value) {
    return Integer.parseInt(value);       // 可能抛非受检异常
}

上例的 IOException 是受检异常，因此 load 必须捕获或在签名中声明它。parseInt 抛出的 NumberFormatException 属于非受检异常，所以方法可以省略声明。

设计 API 时，受检异常适合显式提醒调用方采取行动的失败。非受检异常可以表达参数、状态或编程错误，也适合避免调用链每层重复声明的失败。分类依据是继承关系，恢复策略仍取决于场景，而非异常名称或严重程度。

3. 抛出、声明与捕获

必会卡 · 项目中应该怎样处理异常

失败发生后，方法可以抛出异常，由当前层处理或继续传给调用方。这条传播路径涉及三个关键字：

throw 抛出一个具体异常对象。
throws 在方法签名中声明异常传播范围。
catch 捕获匹配的异常，让当前层执行恢复或转换逻辑。

Order loadOrder(long id) {
    try {
        return repository.find(id);
    } catch (SQLException cause) {
        throw new OrderStoreException("load order " + id, cause);
    }
}

这里把数据库异常转换成应用定义的 OrderStoreException，让调用方依赖稳定的失败类型。构造器中的 cause 保存原始异常，排查时仍能看到数据库失败的原因。

捕获异常前，要明确当前层能够执行哪种处理策略：

对临时失败重试，并限定次数和总耗时。
降级为业务允许的替代结果。
清理当前层负责的资源或未完成操作。
补充订单编号等信息，转换异常后继续传播。
将内部异常映射成调用方需要的错误结果。

当前层缺少处理策略时，应让异常继续传播。捕获后返回 null 或空结果，会让调用方把执行失败误认为没有数据。

3.1 错误边界

错误边界是决定如何结束本次请求或任务的位置。Web 请求、消息消费者和定时任务的入口都可以承担这个职责。

异常到达边界后，入口把它转换为对外错误码、消息重试结果或任务状态。日志同时记录追踪标识，让一次失败能关联回对应请求。

同一个异常不应在每一层重复打印完整堆栈。中间层负责补充语义并传播，边界层负责形成一次可诊断记录。

4. 常见处理规则

必会卡 · 项目中应该怎样处理异常

异常处理需要保留失败信息，同时让正常分支保持清楚。实现时遵循以下传播与清理规则：

catch 中明确执行恢复、转换或传播，空 catch 会直接隐藏失败。
转换异常时，把原异常作为 cause 保留下来。
循环结束或缓存未命中属于预期分支，使用条件判断和正常返回值表达。
finally 用于清理资源并正常结束，在其中 return 会覆盖此前的返回值或异常。
捕获 InterruptedException 后继续传播，或用 Thread.currentThread().interrupt() 恢复中断标记。

try {
    queue.take();
} catch (InterruptedException interrupted) {
    Thread.currentThread().interrupt();
    return;
}

示例在结束当前操作前恢复中断标记，让外层代码仍能识别取消请求。直接吞掉中断会丢失这个信号。

5. try-with-resources 与资源关闭

必会卡 · try-with-resources 怎样保证资源关闭

try-with-resources 把资源使用和关闭放在同一个语法结构中。资源实现 AutoCloseable 接口后，就提供了可由该语法调用的 close() 方法。控制流因执行完毕、return 或异常离开 try 主体时，都会调用资源的关闭方法。

try (
    InputStream input = Files.newInputStream(source);
    OutputStream output = Files.newOutputStream(target)
) {
    input.transferTo(output);
}

上例打开输入流和输出流，随后复制数据。离开这个代码块时，遵循以下关闭规则：

多个资源按声明的逆序关闭，这里先关闭 output，再关闭 input。
初始化中途失败时，已经成功创建的资源仍会关闭。
主体与 close() 同时失败时，保留主体异常。关闭异常通过 getSuppressed() 读取。

这些关闭异常称为抑制异常，保存于主体异常的 suppressed 列表中。它们仍可用于诊断，只是由主体异常代表本次失败向外传播。

try {
    run();
} catch (Exception failure) {
    for (Throwable closeFailure : failure.getSuppressed()) {
        // 记录资源关闭失败
    }
}

5.1 资源所有权

关闭资源前，要确定哪个方法负责它的生命周期。当前方法只关闭自己创建或明确接管的资源。

调用方传入的流还可能用于后续操作，借用方应把关闭职责留给所有者。包装流还会按自身约定关闭底层流，因此 API 要写清传入资源是借用还是移交。

6. finally 与返回值

必会卡 · try 返回后 finally 修改局部变量，返回值会改变吗？

判断 finally 是否影响返回值，要看返回表达式在什么时候求值。执行 return 时，程序先算出表达式的值，再执行 finally，最后完成返回。因此，在 finally 中修改局部变量后，返回的仍是此前求出的基本类型值：

static int result() {
    int value = 1;
    try {
        return value;
    } finally {
        value = 2;
    }
}
System.out.println(result()); // 1