Java 异常体系：从 “try-catch” 到自定义异常的最佳实践

（1）Checked Exception（受检异常）：在编译期强制要求处理的异常（如IOException、SQLException）。编译器会检查这类异常，若未通过try-catch捕获或throws声明抛出，程序将无法编译。其设计初衷是提醒开发者 “此处可能出现可预见的错误，必须处理”。

（2）Unchecked Exception（非受检异常）：继承自RuntimeException的异常（如NullPointerException、ArrayIndexOutOfBoundsException）。编译期不强制处理，通常由程序逻辑错误导致，开发者应通过优化代码避免其发生，而非单纯捕获。

2. Checked 与 Unchecked 异常的使用场景

使用 Checked 异常：当异常的发生是 “外部环境导致且开发者可通过处理恢复” 时，例如读取文件时的IOException（可提示用户检查文件路径后重试）。

使用 Unchecked 异常：当异常是 “程序逻辑错误” 导致时，例如调用null对象的方法（NullPointerException），此时应通过修正代码（如增加非空判断）避免，而非依赖try-catch。

二、常见异常解析：从成因到防御性编程

了解常见异常的产生原因，是写出健壮代码的前提。以下解析几个高频异常的本质及规避方法。

1. NullPointerException（NPE）：最 “经典” 的逻辑错误

成因：调用null对象的方法或访问其字段（例如String s = null; s.length();）。

防御性编程策略：

方法参数校验：在方法入口判断关键参数是否为null，例如：

public void doSomething(String input) {
    if (input == null) {
        throw new IllegalArgumentException("输入参数不能为空"); // 提前暴露错误
    }
    // 业务逻辑
}

使用Objects.requireNonNull()：Java 7 引入的工具类，可简洁地进行非空校验：

Objects.requireNonNull(input, "input must not be null");

避免链式调用：a.b().c()中若a或b()返回null，将直接触发 NPE，建议拆分调用并增加判断。

2. ConcurrentModificationException：迭代中的 “暗坑”

成因：当使用迭代器遍历集合（如ArrayList）时，若同时通过集合自身方法（如add()、remove()）修改集合结构，迭代器会检测到并发修改并抛出此异常。

本质：迭代器是集合的 “快照” 视图，直接修改集合会导致视图与实际数据不一致，为避免迭代混乱，迭代器主动抛出异常。

解决方案：

使用迭代器自带的remove()方法（仅适用于删除当前元素）；

若需添加元素，可使用CopyOnWriteArrayList（并发安全集合，迭代时遍历的是原集合快照，修改操作不影响迭代）；

避免在迭代中修改集合，若必须修改，可先记录需要操作的元素，迭代结束后统一处理。

3. ClassCastException：类型转换的 “陷阱”

成因：将对象强制转换为不兼容的类型（例如Object obj = "hello"; Integer i = (Integer) obj;）。

规避方法：

转换前通过instanceof判断类型兼容性：

if (obj instanceof Integer) {
    Integer i = (Integer) obj;
}

优先使用泛型（如List<String>），让编译器在编译期检查类型，减少运行时转换错误。

三、自定义异常：让异常传递 “业务语义”

Java 内置异常仅能描述通用错误，而业务场景中往往需要更具体的异常信息（如 “用户不存在”“余额不足”）。此时，自定义异常是传递业务语义的最佳方式。

1. 何时需要自定义异常？

当内置异常无法准确描述业务错误时（例如 “订单状态不允许取消”，无对应的内置异常）；

需通过异常携带业务信息时（如错误码、用户提示消息）；

希望通过异常类型区分业务场景时（例如UserNotFoundException和OrderNotFoundException，便于上层代码针对性处理）。

2. 自定义异常的设计原则

继承合理的父类：

若希望异常被强制处理（如业务校验失败需显式处理），继承Exception（Checked 异常）；
若属于运行时逻辑错误（如参数格式错误），继承RuntimeException（Unchecked 异常）。

包含业务信息：添加错误码、提示消息等字段，例如：

public class UserNotFoundException extends RuntimeException {
    private String errorCode; // 错误码，如"USER_NOT_FOUND"
    
    public UserNotFoundException(String errorCode, String message) {
        super(message);
        this.errorCode = errorCode;
    }
    
    // getter方法
}

提供清晰的构造方法：至少包含String message参数的构造方法，便于传递错误描述。

避免过度设计：不必为每个细微错误创建独立异常，可通过错误码区分同一类异常的不同场景（如BusinessException+ 不同errorCode）。

四、避坑指南：远离异常处理的 “反模式”

即使掌握了异常体系，不合理的处理方式仍会导致程序难以调试或隐藏潜在问题。以下是需要警惕的反模式：

1. 异常吞噬（Empty Catch Block）

表现：捕获异常后不做任何处理，例如：

try {
    // 可能出错的代码
} catch (IOException e) {
    // 空块，异常被“吞噬”
}

危害：异常发生后无任何日志或提示，开发者无法得知错误发生，问题排查难度极大。

正确做法：至少记录异常日志（如使用 SLF4J），必要时向上抛出：

catch (IOException e) {
    log.error("文件读取失败", e); // 记录完整堆栈信息
    throw new BusinessException("操作失败，请稍后重试", e); // 向上传递异常
}

2. 过度使用Exception捕获所有异常

表现：用catch (Exception e)捕获所有可能的异常，例如：

try {
    // 复杂业务逻辑
} catch (Exception e) {
    log.error("发生错误", e);
}

危害：

会捕获到本不应处理的异常（如RuntimeException可能是逻辑错误，应修复而非捕获）；

掩盖了特定异常的处理逻辑，导致无法针对性处理（如SQLException需要回滚事务，而IOException可能只需提示用户）。

正确做法：精准捕获特定异常，仅处理已知且能处理的异常，未知异常应让其向上传递：

try {
    // 代码
} catch (IOException e) {
    // 处理IO相关异常
} catch (SQLException e) {
    // 处理数据库相关异常
}

3. 不指定异常原因（丢失堆栈信息）

表现：抛出新异常时不携带原始异常，例如：

try {
    // 代码
} catch (IOException e) {
    throw new BusinessException("操作失败"); // 丢失原始异常堆栈
}

危害：原始异常的堆栈信息被丢失，难以追溯错误根源（例如 “操作失败” 可能由文件不存在或权限不足导致，原始IOException才能说明具体原因）。

正确做法：通过构造方法传递原始异常（异常链）：

catch (IOException e) {
    throw new BusinessException("操作失败", e); // 保留原始异常
}

4. 在finally块中使用return

表现：在finally中返回结果，覆盖try或catch中的返回值，例如：

public int test() {
    try {
        return 1;
    } catch (Exception e) {
        return 2;
    } finally {
        return 3; // 最终返回3，覆盖try中的1
    }
}

危害：finally块的return会覆盖之前的返回值，导致逻辑混乱且难以调试。

正确做法：finally仅用于释放资源（如关闭流、连接），不执行业务逻辑或返回操作。