Java编程语言异常处理详解：try、catch与自定义异常

异常处理不是把报错“压下去”，而是让程序在错误发生时有明确的应对方式：能恢复的，采取补救或重试；不能恢复的，向调用方传递失败信息；无论如何都必须执行的清理工作，则可靠地完成。设计得当的异常处理能让接口行为更清楚，也有助于定位问题。设计不当则可能掩盖故障、泄露实现细节，甚至造成资源未释放。

本文从 Java 异常的分类讲起，说明 try、catch、finally、throw、throws 与自定义异常的用法，并讨论参数校验、资源管理和安全边界。示例以常见 Java 版本语法编写，可分别保存为对应的类名文件后编译运行。

一、认识 Java 异常体系

Java 中所有异常和错误都属于 Throwable 的子类。它主要分为两支：

• Error 表示通常由 JVM 或运行环境报告的严重问题，例如 OutOfMemoryError。一般业务代码不应试图捕获后继续运行。
• Exception 表示程序可能需要处理的异常情况。其中，除 RuntimeException 及其子类以外的异常通常是受检异常；RuntimeException 及其子类是非受检异常。

受检异常必须被当前方法捕获，或在方法声明中通过 throws 声明向上交给调用方。例如，文件操作中的 IOException 通常属于受检异常。NullPointerException、IllegalArgumentException 等运行时异常不要求显式捕获或声明。

“受检”不代表一定应该捕获，“非受检”也不代表可以忽略。异常的类型决定了编译器如何检查调用代码；具体由谁处理，则应根据当前层是否有足够的信息恢复、转换或补充上下文来决定。

二、try、catch 与异常匹配

把可能抛出异常的代码放入 try 块，在一个或多个 catch 块中处理。运行时会按书写顺序查找能够匹配实际异常类型的第一个 catch。

public class CatchExample {
    public static void main(String[] args) {
        String text = "42";

        try {
            int value = Integer.parseInt(text);
            System.out.println("解析结果：" + value);
        } catch (NumberFormatException e) {
            System.err.println("输入不是有效整数：" + text);
            e.printStackTrace();
        }
    }
}

保存为 CatchExample.java，执行 javac CatchExample.java 和 java CatchExample 即可运行。示例捕获了具体的 NumberFormatException，而不是笼统地捕获所有异常。这样既能表达预期处理范围，也不容易把代码中的其他缺陷一并吞掉。

当几种异常确实采用同一种处理方式时，可以在 Java 7 及之后的版本中使用多重捕获：

try {
    // 可能出现多种可预期异常的操作
} catch (NumberFormatException | IllegalArgumentException e) {
    System.err.println("参数格式或取值不合法：" + e.getMessage());
}

多重捕获中的类型不能存在父子继承关系。例如，不能把 NumberFormatException 与它的父类 IllegalArgumentException 同时放在同一组中；否则父类已经覆盖子类，编译器会报错。若处理方式不同，应拆成多个 catch；若必须同时捕获父类和子类，则把更具体的子类写在前面。

三、throw 与 throws：抛出异常和声明异常

throw 用于在代码中实际抛出一个异常对象；throws 写在方法签名上，表示该方法可能把指定的受检异常交给调用方处理。二者作用不同，不能互换。

import java.io.IOException;

public class ThrowExample {
    static void load(boolean shouldFail) throws IOException {
        if (shouldFail) {
            throw new IOException("数据读取失败");
        }
        System.out.println("读取完成");
    }

    public static void main(String[] args) {
        try {
            load(true);
        } catch (IOException e) {
            System.err.println("调用方处理：" + e.getMessage());
        }
    }
}

在这个例子中，throw new IOException(...) 创建并抛出了异常；throws IOException 则让方法签名明确告知调用者需要考虑这一失败路径。如果抛出的是受检异常，当前方法需要捕获它，或者在签名中声明它。运行时异常不受这一编译期要求约束，但仍可以出现在方法的运行过程中。

不要为了让编译通过而随意把受检异常包装成运行时异常，也不要在每一层都重复捕获并重新抛出。异常应由真正能够处理它，或能够增加有用上下文的层处理。

四、finally：清理工作与控制流边界

finally 通常用于执行不论操作成功还是失败都需要完成的清理代码，例如关闭资源或释放锁。即使 try 或 catch 中执行了 return，正常情况下 finally 仍会执行。不过，进程被强制终止、虚拟机崩溃等情形不在保证之列，因此不能把 finally 当作绝对可靠的持久化机制。

public class FinallyExample {
    static int calculate() {
        try {
            return 10;
        } finally {
            System.out.println("执行清理逻辑");
        }
    }

    public static void main(String[] args) {
        System.out.println("返回值：" + calculate());
    }
}

这里先打印“执行清理逻辑”，再打印返回值。需要特别注意：不要在 finally 中使用 return，也不要在其中抛出新的异常来覆盖原有异常。这样的控制流会使调用方看到的结果与 try 中发生的情况不一致，排查问题十分困难。对于关闭文件、流等资源，优先考虑下一节的 try-with-resources。

五、优先使用 try-with-resources 管理资源

实现 AutoCloseable 接口的资源可以放在 try 后面的括号中。代码离开 try 块时，Java 会自动调用资源的 close() 方法，包括正常结束和发生异常的情况。多个资源会按创建顺序的相反顺序关闭。

import java.io.ByteArrayInputStream;
import java.io.IOException;

public class ResourceExample {
    public static void main(String[] args) {
        byte[] data = {65, 66, 67};

        try (ByteArrayInputStream input = new ByteArrayInputStream(data)) {
            int value;
            while ((value = input.read()) != -1) {
                System.out.println((char) value);
            }
        } catch (IOException e) {
            System.err.println("读取失败");
            e.printStackTrace();
        }
    }
}

保存为 ResourceExample.java 即可编译运行。虽然 ByteArrayInputStream 的实际读取通常不会产生 I/O 故障，但它的 read() 方法声明了可能发生的受检异常，因此示例仍需处理或声明 IOException。

如果资源关闭时也发生异常，而主体代码已经抛出异常，try-with-resources 会保留主体异常，并将关闭时的异常作为“被抑制异常”记录在主异常上。可通过 getSuppressed() 查看。相比手动在 finally 中关闭资源，这种写法更不容易丢失原始故障信息。

六、自定义异常：表达领域失败

标准异常无法清晰表达某个业务领域中的失败时，可以定义自己的异常类型。自定义异常不应只是换个名字重复标准异常的含义；它的价值在于让调用方能够针对特定失败分类处理，或携带稳定、明确的上下文。

下面定义一个受检异常表示余额不足，并实现最小可运行示例：

class InsufficientBalanceException extends Exception {
    public InsufficientBalanceException(String message) {
        super(message);
    }
}

class Account {
    private int balance;

    public Account(int initialBalance) {
        if (initialBalance < 0) {
            throw new IllegalArgumentException("初始余额不能为负数");
        }
        this.balance = initialBalance;
    }

    public void withdraw(int amount) throws InsufficientBalanceException {
        if (amount <= 0) {
            throw new IllegalArgumentException("取款金额必须大于零");
        }
        if (amount > balance) {
            throw new InsufficientBalanceException("余额不足");
        }
        balance -= amount;
    }

    public int getBalance() {
        return balance;
    }
}

public class AccountExample {
    public static void main(String[] args) {
        Account account = new Account(100);

        try {
            account.withdraw(150);
            System.out.println("当前余额：" + account.getBalance());
        } catch (InsufficientBalanceException e) {
            System.out.println("取款未完成：" + e.getMessage());
        }
    }
}

这里的自定义异常继承 Exception，因此属于受检异常，withdraw 必须捕获它或声明 throws。若某类失败不适合在调用方逐层显式处理，例如违反方法前置条件，通常可以使用 IllegalArgumentException 等运行时异常，而不是为每一种参数错误都定义受检异常。

选择受检还是非受检异常，应考虑 API 的使用方式：调用方是否能够合理恢复、是否有必要在编译期强制提醒调用方，以及这种约束是否会使接口变得笨重。不存在适用于所有项目的单一规则，但选择应当一致，并通过文档说明失败条件。

七、包装异常时保留原始原因

有时底层异常需要转换为当前层更有意义的异常，例如把数据库驱动异常转成仓储层异常。包装时应把原异常作为原因传入构造函数，保留完整因果链，便于日志和排查。

class DataAccessException extends RuntimeException {
    public DataAccessException(String message, Throwable cause) {
        super(message, cause);
    }
}

class Repository {
    void load() {
        try {
            throw new IllegalStateException("底层连接不可用");
        } catch (IllegalStateException e) {
            throw new DataAccessException("加载记录失败", e);
        }
    }
}

异常原因通过 getCause() 获取，打印堆栈时也会显示原因链。不要只把原异常的消息拼接进新异常，却不保留原异常对象；否则原始堆栈可能丢失。若当前层既没有新增信息，也没有改变调用方需要看到的异常语义，直接让异常继续传播通常更合适。

八、参数校验：检查明确的前置条件

参数校验适合用于边界清晰的前置条件，例如要求对象非空、整数必须为正、字符串长度不得超过接口约定。校验应尽量靠近接收参数的公开方法或系统边界，避免非法值在程序中传播很久才触发故障。

public class ValidationExample {
    static String repeat(String text, int count) {
        if (text == null) {
            throw new IllegalArgumentException("text 不能为 null");
        }
        if (count < 0) {
            throw new IllegalArgumentException("count 不能为负数");
        }
        if (count > 1000) {
            throw new IllegalArgumentException("count 不能超过 1000");
        }

        StringBuilder result = new StringBuilder();
        for (int i = 0; i < count; i++) {
            result.append(text);
        }
        return result.toString();
    }

    public static void main(String[] args) {
        System.out.println(repeat("Java", 2));
    }
}

示例中的 1000 是该方法自行定义的业务限制，不是 Java 语言或 StringBuilder 的通用参数上限。真实项目应根据资源预算、接口契约和使用场景确定限制，并在文档、校验和测试中保持一致。

校验不应只停留在表面。例如，字符串长度限制要考虑所使用的长度定义：Java 的 String.length() 返回 UTF-16 代码单元数量，不等同于用户看到的字符数，也不等同于编码后的字节数。若限制针对网络报文或文件大小，需按实际编码计算字节；若针对用户可见字符，则应采用与需求相符的 Unicode 处理方式。

此外，参数校验不能替代数据库约束、权限检查或文件系统权限控制。输入在校验后仍可能因并发状态变化或外部环境变化而失败；重要约束应在真正执行操作的边界再次确保。

九、异常处理中的安全边界

• 异常不是安全防线。 抛出或捕获异常不能代替身份认证、授权、输入编码、资源权限、事务约束等安全控制。攻击者可以绕过某个应用层分支，真正的安全检查应位于可信的执行边界。
• 不要把内部细节直接返回给外部用户。 异常消息、堆栈和底层错误可能包含路径、主机名、查询语句或其他实现信息。面向用户应返回稳定、有限的提示；详细原因记录到受控日志中，并妥善限制日志访问。
• 日志也需要审慎处理。 不要无差别记录密码、令牌、密钥或完整敏感请求。记录异常时保留足够的故障上下文，同时遵循数据最小化和访问控制要求。
• 不能把异常当作正常分支的替代品。 例如，对高频、预期的“没有结果”场景，若 API 提供了返回值、状态对象或其他更清楚的表达，应优先使用更合适的表示方式。

捕获一个异常并不自动意味着程序安全、事务回滚或数据未被修改。操作在抛出异常前可能已经产生部分副作用。是否需要回滚，应依赖事务机制和业务操作的具体语义，而不是仅仅依赖 catch 块。

十、常见错误及改进方式

1. 捕获后什么也不做

catch (Exception e) {} 会让故障消失在调用方视野里，程序可能继续使用无效状态。若异常确实可忽略，应把忽略的条件和理由写清楚；否则应记录必要上下文、转换异常，或让异常继续传播。

2. 过度捕获父类异常

在整个方法外包一层 catch (Exception)，可能把程序缺陷和预期失败混为一谈。只捕获当前层能够处理的异常类型。程序入口或任务调度边界有时需要兜底捕获以隔离单次任务失败，但仍应记录故障并确保失败状态不会被误报为成功。

3. 捕获 Throwable 并继续运行

Throwable 同时包含 Error，捕获后盲目继续通常不安全。除非实现特定的底层框架或运行时设施，并且清楚了解后果，否则不要在普通业务代码中捕获 Throwable。

4. 只打印消息，不保留堆栈

仅调用 e.getMessage() 可能不足以判断故障位置。面向用户可以隐藏内部细节，但诊断日志应在合适的位置保留异常对象及其原因链，并避免同一异常在多层重复记录造成日志噪声。

5. 用异常控制普通流程

如果输入是否为空、集合是否包含某项等情况可以通过条件判断清楚表达，就不要依赖捕获异常来实现常规分支。异常适合表示非正常失败，不适合代替所有返回值和条件判断。

6. 在 finally 中返回或抛出新异常

这可能覆盖 try 中的返回值或原始异常。清理代码应尽量简单，并优先使用 try-with-resources 管理可关闭资源。

7. 误以为声明 throws 就完成了异常处理

throws 只是把处理责任交给调用方，并不代表异常已经恢复。调用方应了解方法可能失败的条件；公共 API 也应在文档中说明相关异常及其含义。

十一、选择处理方式的简明步骤

1. 先判断是否为真正的失败。 正常业务状态优先用返回值或明确的状态模型表达。
2. 在边界校验可验证的前置条件。 给出有意义的错误类型和稳定信息，不要假设校验能消除所有并发及外部故障。
3. 确认当前层能否恢复。 能重试、回退或转换为明确结果时，在这一层处理；否则保留异常，让更上层决策。
4. 需要转换时保留原因。 给异常补充当前层的语境，但避免重复包装和丢失原始堆栈。
5. 清理资源使用 try-with-resources。 不把资源释放依赖于普通的执行路径。
6. 区分内部诊断与外部反馈。 对外给出适当信息，对内保留必要且受保护的诊断数据。

总结

理解 Java 异常，关键不只是记住语法：try 与 catch 用于划定处理边界，throw 抛出异常对象，throws 声明可能交给调用方处理的受检异常；finally 用于清理但不应承载覆盖控制流的操作；资源管理通常优先选择 try-with-resources。自定义异常应服务于清晰的领域语义，包装异常要保留原因。参数校验、异常捕获和安全控制各有职责，不能相互替代。把异常类型、传播路径、恢复策略和对外信息设计清楚，程序才既容易维护，也更不容易掩盖真正的问题。