异常处理

是什么，为什么存在

异常是 Java 表示非正常完成的一种对象协议。每个异常都是 Throwable 或其子类的实例，可以携带类型、消息、原因和创建时的栈轨迹。方法遇到无法按正常路径完成的情况时，可以抛出异常，把处理决定交给调用方，而不必把错误码混入每个返回值。

异常不会自动让程序“恢复”。它提供的是一种分离机制：底层代码报告失败，知道业务策略的边界决定重试、降级、转换、记录还是终止。如果没有匹配的处理器，异常会继续越过调用者，最终交给线程的未捕获异常处理机制。

你会在文件、网络、数据库、反射和并发 API 中遇到检查型异常，也会在参数校验、非法状态和程序错误中遇到运行时异常。阅读一个 API 时，既要看方法签名中的 throws，也要看文档记录的非检查型异常及其触发条件。

Throwable 层次

Java 的异常层次以 Throwable 为根。Exception 分支用于应用通常可能处理的失败，Error 分支表示 JVM、链接或资源层面的严重问题；普通业务代码通常不应捕获 Error 后继续运行。

检查型异常（checked exception） 是编译器执行捕获或声明检查的异常类。Java 语言规范精确定义为 Throwable 体系中除 RuntimeException 分支和 Error 分支以外的类。调用可能抛出检查型异常的方法时，当前方法必须用 catch 处理，或者在 throws 子句中继续声明。

非检查型异常（unchecked exception） 包括运行时异常类和错误类。编译器不强制把它们写进 throws，但“不强制”不等于“不需要设计”：公开方法仍应记录重要的参数约束与状态约束，调用方也不应靠捕获 NullPointerException 来替代输入校验。

选择检查型还是非检查型

类型选择取决于调用方是否应被编译器强制做出决定。外部数据读取失败、协议握手失败等情况，调用方往往需要传播、转换或恢复，检查型异常可以把这项责任放进签名。违反方法前置条件、对象状态不允许操作等问题通常使用 IllegalArgumentException 或 IllegalStateException 一类的非检查型异常。

“是否可能恢复”不是机械规则。同一种底层 IOException 在命令行入口可能意味着报告后退出，在服务层可能被转换为领域异常，在批处理单元中也可能只终止当前记录。异常类型应描述失败的语义，捕获位置则表达当前层能够采取的策略。

自定义异常应提供稳定的领域名称和调用方需要的结构化上下文。不要把敏感令牌、完整请求体或凭据拼进消息；异常消息经常进入日志、监控或 API 错误映射。若包装另一个失败，应通过带 cause 的构造器保存原始异常。

四个关键语法元素

throw 后面是一个 Throwable 对象，它让当前表达式或语句非正常完成。throws 位于方法或构造器签名中，声明可能向调用方传播的检查型异常类型；它本身不会创建或抛出对象。

try 划定可能失败的操作范围，catch 按异常对象的运行时类型选择处理器。finally 用于无论正常还是非正常路径都要执行的动作，但可关闭资源时通常应优先使用 try-with-resources，因为它保留主异常与关闭异常之间的关系。

多重捕获可以把处理策略相同、彼此无继承关系的类型写成 catch (TypeA | TypeB error)。多重捕获参数隐式为 final，而且不能把父类和子类同时列入同一个联合类型。

工作原理

抛出、匹配与栈展开

执行 throw，或由表达式、方法调用、类加载等操作产生异常后，当前执行路径会非正常完成。运行时先检查包围抛出点的 try，按照源码顺序选择第一个能接收该异常运行时类型的 catch。没有匹配项时，当前方法退出，搜索继续转到调用方。

这个过程称为栈展开。异常离开一个同步方法或 synchronized 语句时，相应监视器仍会按语言规则释放；已经注册的 finally 和资源关闭动作也会在传播路径上运行。异常不会回到抛出点继续执行，除非应用在更高层明确重试整个操作。

catch 的顺序从具体到一般。NumberFormatException 是 IllegalArgumentException 的子类，因此具体处理器必须位于一般处理器之前；反过来写会因后一个分支不可达而无法编译。多个处理器不是“最具体类型自动胜出”，真正规则是选择源码中第一个兼容项。

处理器结束后，控制流从整个 try 语句之后继续，而不是回到失败语句的下一行。如果处理器重新抛出同一对象，原栈轨迹和身份得以保留；如果建立新的抽象层，则应创建领域异常并把旧异常传为原因。

编译期检查

编译器分析表达式和语句可能抛出的检查型异常。某个检查型异常只有在当前范围被兼容的 catch 捕获，或由所在方法、构造器的 throws 覆盖时，代码才通过编译。这让失败成为调用契约的一部分，却不能证明运行时一定会抛出，也不能列出所有非检查型失败。

覆盖方法不能随意扩大检查型异常契约。实现类可以不再抛出原声明的检查型异常，或缩小为其子类，但不能让通过父类型调用的代码突然面对一个更宽的新检查型异常。非检查型异常不受这项 throws 限制。

泛型和精确重新抛出会让编译器推断比变量声明更窄的可抛类型。基础代码不应为追求短签名而滥用技巧；首先让边界语义清晰，再利用编译器保持声明准确。

finally 的控制流

finally 在 try 或所选 catch 结束后运行，然后才完成返回或继续传播。它适合恢复内存中的不变量、释放不能由 AutoCloseable 表示的锁，以及执行必须与当前作用域绑定的清理。

如果 finally 自己用 return、throw、break 或 continue 非正常完成，它会替换此前的返回值或异常。这是危险的控制流：原失败可能完全消失。因此，finally 应专注于不会改变主结果的清理，并避免 return。

“一定执行”也不是进程级保证。JVM 终止、进程崩溃或机器失效时，不能依靠 finally 完成持久化承诺。需要跨进程保证的工作应使用事务、幂等恢复或外部协调，而不是只靠语言级清理。

try-with-resources

try-with-resources 管理实现 AutoCloseable 的对象。资源初始化成功后，离开 try 时会自动调用 close()；多个资源按初始化的相反顺序关闭。如果后续资源初始化失败，先前已经成功初始化的资源仍会关闭。

Java 9 起，资源头可以引用已经明确赋值的 final 或事实 final 变量，例如 try (reader)。资源变量不能在受保护范围内重新赋值，这让关闭目标保持确定。

当主体和 close() 都失败时，主体异常继续作为主异常传播，关闭异常成为 被抑制异常（suppressed exception） 。它们可以通过 getSuppressed() 读取。若主体正常完成而关闭失败，关闭异常本身就是需要传播的异常；被抑制不等于被忽略。

原因与被抑制异常

异常原因（exception cause） 回答“哪个较低层失败导致了当前异常”，由构造器或 initCause() 建立，并通过 getCause() 访问。异常转换时保留原因，可以让上层使用领域词汇，同时让诊断工具继续看到 IOException、SQLException 等根因。

被抑制异常回答的是另一件事：“传播主失败的同时，还有哪些清理失败发生”。原因通常形成语义链，被抑制异常则是附着在某个主异常上的并列次要失败。日志和错误报告工具需要保留两者，不能只输出 getMessage()。

栈轨迹通常在线程创建异常对象时记录。重复包装会增加上下文，但每一层都记录并立即重新抛出，也会产生重复日志。选择一个拥有请求、任务或进程结果的边界记录完整异常对象，中间层只在能增加语义时转换。

示例

精确捕获运行时异常

第一个示例把文本解析失败与合法整数的领域校验分开。两个异常都属于非检查型异常，但调用边界仍然按不同策略处理。

NumberFormatException 必须写在其父类 IllegalArgumentException 之前。代码只捕获它能转换成用户输入结果的异常；若 parse() 因无关程序错误失败，不会被一个宽泛的 catch (Exception) 伪装成输入格式问题。

转换检查型异常并保留原因

下一层 API 不希望把读取实现细节暴露给调用方，因此把 IOException 转换为领域内的检查型异常。构造器保留 cause，调用方既能看到稳定的领域消息，也能检查底层类型和消息。

import java.io.IOException;
import java.io.Reader;
public class ExceptionTranslation {
    static final class RuleLoadException extends Exception {
        RuleLoadException(String message, Throwable cause) {
            super(message, cause);
        }
    }

    static final class BrokenReader extends Reader {
        @Override
        public int read(char[] buffer, int offset, int length) throws IOException {
            throw new IOException("storage offline");
        }

        @Override
        public void close() {}
    }

    static char loadFirstRule(Reader source) throws RuleLoadException {
        try (source) {
            int value = source.read();
            if (value == -1) {
                throw new RuleLoadException("Shipping rules are empty", null);
            }
            return (char) value;
        } catch (IOException cause) {
            throw new RuleLoadException("Could not load shipping rules", cause);
        }
    }
    public static void main(String[] args) {
        try {
            loadFirstRule(new BrokenReader());
        } catch (RuleLoadException error) {
            System.out.println(error.getMessage());
            System.out.println("cause=" + error.getCause().getClass().getSimpleName()
                    + ": " + error.getCause().getMessage());
        }
    }
}

Could not load shipping rules
cause=IOException: storage offline

try (source) 使用事实 final 的方法参数，并保证读取成功或失败时都关闭它。这个示例只在已知存在原因的失败路径读取 getCause()；通用诊断代码必须允许原因是 null。

观察关闭顺序与被抑制异常

资源示例故意让主体和两个 close() 都失败，以显示哪一个异常拥有传播优先级。生产资源的 close() 应尽量释放底层资源后再报告失败，但调用方仍要能够看到关闭问题。

public class ResourceFailures {
    static final class DemoResource implements AutoCloseable {
        private final String name;

        DemoResource(String name) {
            this.name = name;
            System.out.println("open " + name);
        }

        @Override
        public void close() throws Exception {
            System.out.println("close " + name);
            throw new Exception("close failed: " + name);
        }
    }

    public static void main(String[] args) {
        try (var input = new DemoResource("input");
             var output = new DemoResource("output")) {
            System.out.println("process");
            throw new Exception("processing failed");
        } catch (Exception primary) {
            System.out.println("primary=" + primary.getMessage());
            for (Throwable suppressed : primary.getSuppressed()) {
                System.out.println("suppressed=" + suppressed.getMessage());
            }
        }
    }
}

open input
open output
process
close output
close input
primary=processing failed
suppressed=close failed: output
suppressed=close failed: input

输出先显示逆序关闭。主体的 processing failed 保持为主异常，随后发生的两个关闭失败按发生顺序出现在 getSuppressed() 中。手写嵌套 finally 很容易丢失这种关系。

捕获中断后恢复状态

InterruptedException 通常会在抛出时清除线程的中断状态。如果当前方法不能继续声明它，但上层仍需要观察取消请求，就应在完成本层清理后恢复状态。

public class PreserveInterrupt {
    static void waitForSignal() {
        try {
            Thread.sleep(1_000);
        } catch (InterruptedException interrupted) {
            Thread.currentThread().interrupt();
            System.out.println("wait cancelled");
        }
    }

    public static void main(String[] args) {
        Thread.currentThread().interrupt();
        waitForSignal();
        System.out.println("interrupted=" + Thread.currentThread().isInterrupted());
    }
}

wait cancelled
interrupted=true

main 先设置当前线程的中断状态，因此 sleep() 立即抛出，示例不依赖计时。处理器恢复状态后，上层仍能通过 isInterrupted() 看到取消信号。另一种正确策略是让方法声明并传播 InterruptedException。

陷阱

延伸阅读

• Java 语言规范第 11 章：异常
• Java 语言规范第 14.20 节：try 语句
• Java SE 25 API：Throwable
• Java SE 25 API：AutoCloseable
• Java SE 25 API：InterruptedException