Java 异常体系全链路：受检异常到底该不该用

Java 异常体系全链路：受检异常到底该不该用

异常处理是 Java 面试的常考点。异常体系怎么分？受检异常争议在哪？try-with-resources 底层怎么工作？本文一次讲清。

一、Java 异常体系全景

┌─────────────────────────────────────────────────────────────┐
│                  Java 异常体系层级                              │
│                                                             │
│                     Throwable                                │
│                    /        \                                │
│               Error          Exception                        │
│              (非检查)         /          \                    │
│           ┌──────────┐  RuntimeException   其他Exception       │
│           │OutOfMemory│  (非检查/unchecked)  (检查/checked)   │
│           │StackOver- │  ┌────────────┐   ┌──────────────┐   │
│           │  flowError│  │NullPointer │   │IOException   │   │
│           │NoClassDef │  │IndexOutBnds│   │SQLException  │   │
│           │  FoundErr │  │ClassCast   │   │ClassNotFoundException│
│           └──────────┘  │Arithmetic  │   │...           │   │
│                         │ConcurrentMod│  └──────────────┘   │
│                         └────────────┘                      │
│                                                             │
│  非受检异常 (Unchecked): Error + RuntimeException            │
│    → 编译器不强制处理 (可以 try-catch 也可以不处理)           │
│    → 程序错误，应该从代码层面修复                             │
│                                                             │
│  受检异常 (Checked): Exception(非 RuntimeException)          │
│    → 编译器强制处理 (必须 try-catch 或 throws)               │
│    → 外部环境问题，程序可以恢复                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

异常分类详解

// 1. Error: 系统级错误，不应捕获
OutOfMemoryError           // 堆溢出
StackOverflowError         // 栈溢出
NoClassDefFoundError       // 类定义未找到
VirtualMachineError        // 虚拟机错误

// 2. RuntimeException: 编程错误，不应捕获
NullPointerException       // 空指针
ArrayIndexOutOfBoundsException // 数组越界
ClassCastException         // 类型转换错误
IllegalArgumentException   // 非法参数
ArithmeticException        // 算术错误 (除以0)
ConcurrentModificationException // 并发修改

// 3. 受检异常: 外部环境问题，应捕获处理
IOException               // IO 错误
SQLException              // 数据库错误
FileNotFoundException      // 文件未找到
ClassNotFoundException    // 类未找到
InterruptedException      // 线程被中断

受检 vs 非受检异常对比

对比维度	受检异常 (Checked)	非受检异常 (Unchecked)
编译检查	强制 try-catch 或 throws	不强制
继承关系	Exception (非 RuntimeException)	RuntimeException + Error
代表场景	外部环境问题	编程逻辑错误
处理策略	捕获恢复或向上抛	修复代码
示例	IOException, SQLException	NPE, ClassCastException

二、异常处理的五种姿势

1. try-catch-finally

public String readFile(String path) {
    BufferedReader reader = null;
    try {
        reader = new BufferedReader(new FileReader(path));
        return reader.readLine();
    } catch (FileNotFoundException e) {
        log.error("文件不存在: {}", path, e);
        return null;
    } catch (IOException e) {
        log.error("读取失败", e);
        return null;
    } finally {
        // finally 一定会执行 (即使 return 或 throw)
        if (reader != null) {
            try {
                reader.close(); // close 也可能抛异常!
            } catch (IOException e) {
                // 静默关闭
            }
        }
    }
}

2. try-with-resources（JDK 7+）

// 自动关闭实现了 AutoCloseable 的资源
public String readFile(String path) throws IOException {
    try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
        return reader.readLine();
    } // 自动调用 reader.close()，即使发生异常
    // 不需要 finally!
}

// 多个资源
try (FileInputStream fis = new FileInputStream("in.txt");
     FileOutputStream fos = new FileOutputStream("out.txt")) {
    fos.write(fis.readAllBytes());
} // 按声明逆序关闭: fos.close() → fis.close()

try-with-resources 底层原理:

  编译器生成代码等价于:

  FileInputStream fis = new FileInputStream("in.txt");
  try {
      FileOutputStream fos = new FileOutputStream("out.txt");
      try {
          fos.write(fis.readAllBytes());
      } catch (Throwable primary) {
          fos.close(); // 可能抛异常
          throw primary;
      }
      fos.close();
  } catch (Throwable primary) {
      fis.close();
      throw primary;
  }
  fis.close();

  特点:
  ├── 声明顺序的逆序关闭
  ├── 异常抑制: close() 的异常被 addSuppressed
  ├── primary 异常优先抛出
  └── AutoCloseable 接口必需

3. multi-catch（JDK 7+）

// 多个异常类型统一处理
try {
    // ...
} catch (IOException | SQLException e) {
    // IOException 或 SQLException 统一处理
    log.error("操作失败", e);
}
// 注意: 不能用多态父类捕获 (如 IOException | FileNotFoundException 是冗余的)

4. 异常链

public void loadConfig() throws ConfigException {
    try {
        readFile("config.properties");
    } catch (IOException e) {
        // 包装异常，保留原始原因
        throw new ConfigException("配置加载失败", e);
        //                          ↑ cause = 原始异常
    }
}

// 获取原始异常
catch (ConfigException e) {
    Throwable cause = e.getCause(); // 获取原始 IOException
    log.error("配置加载失败，原因: {}", cause.getMessage());
}

5. 自定义异常

// 自定义受检异常
public class BusinessException extends Exception {
    private final int code;

    public BusinessException(int code, String message) {
        super(message);
        this.code = code;
    }

    public BusinessException(int code, String message, Throwable cause) {
        super(message, cause);
        this.code = code;
    }

    public int getCode() { return code; }
}

// 自定义非受检异常
public class ValidationException extends RuntimeException {
    // 类似结构，继承 RuntimeException
}

自定义异常设计原则:

  继承选择:
  ├── 业务异常 → RuntimeException (不强制调用方处理)
  ├── 外部依赖异常 → Exception (强制调用方处理)
  └── 系统级异常 → 不自定义 (用 JVM 内置)

  字段设计:
  ├── 错误码 (code): 便于国际化、程序判断
  ├── 错误消息 (message): 用户可读
  └── 原始异常 (cause): 保留根因

  构造器:
  ├── (code, message): 基本构造
  ├── (code, message, cause): 异常链构造
  └── 都需要提供

三、受检异常的争议

支持受检异常

// 受检异常强制调用方处理
public void readFile() throws IOException {
    // 编译器保证: 调用方必须处理 IOException
}

// 调用方被迫思考: 文件不存在怎么办?
try {
    readFile();
} catch (IOException e) {
    // 不得不处理
}

反对受检异常

// 问题1: 异常传播污染
public void methodA() throws IOException { methodB(); }
public void methodB() throws IOException { methodC(); }
public void methodC() throws IOException { readFile(); }
// 每一层都要 throws IOException，即使中间层不关心

// 问题2: 强制处理导致吞异常
try {
    readFile();
} catch (IOException e) {
    // 被迫 catch，但不知道怎么处理 → 吞掉!
    e.printStackTrace(); // 只打印不处理
}

// 问题3: Lambda 中无法抛受检异常
list.forEach(item -> {
    // readFile(); // ❌ IOException 是受检异常，Lambda 无法抛出
    try {
        readFile();
    } catch (IOException e) {
        throw new RuntimeException(e); // 包装成非受检
    }
});

业界实践

受检异常使用争议:

  Java 设计: 受检异常是 Java 的独特设计
  C#: 完全没有受检异常
  Scala: 完全没有受检异常
  Kotlin: 完全没有受检异常
  Spring 框架: DataAccessException 都是非受检异常
  JDBC: SQLException 是受检异常
  新 Java API (NIO.2): 部分改为非受检

  趋势: 越来越多的框架选择非受检异常
  
  原因:
  1. 受检异常导致代码冗余
  2. Lambda/Stream 不兼容受检异常
  3. 强制处理 → 吞异常比不处理更危险
  4. 大部分异常无法恢复，不如让程序快速失败

四、finally 的陷阱

1. finally 覆盖 return

public int test() {
    try {
        return 1;  // try 中的 return
    } finally {
        return 2;  // finally 中的 return 会覆盖!
    }
}
// 返回 2! (finally 的 return 覆盖了 try 的 return)

// 原理:
// 1. try 中 return 1 → 将 1 放入返回栈
// 2. 执行 finally
// 3. finally 中 return 2 → 将 2 覆盖返回栈
// 4. 最终返回 2

2. finally 中的异常覆盖 try 中的异常

public void test() throws Exception {
    try {
        throw new RuntimeException("try exception");
    } finally {
        throw new RuntimeException("finally exception");
        // finally 的异常覆盖了 try 的异常!
    }
}
// 调用方只看到 "finally exception"
// "try exception" 丢失!

3. finally 修改基本类型不影响返回值

public int test() {
    int x = 1;
    try {
        return x;  // 此时 x=1 的值已存入返回栈
    } finally {
        x = 2;     // 修改 x 不影响已存入的返回值
    }
}
// 返回 1! (不是 2)

4. finally 修改引用类型影响返回值

public List<Integer> test() {
    List<Integer> list = new ArrayList<>();
    try {
        list.add(1);
        return list;  // 返回的是引用
    } finally {
        list.add(2);  // 通过引用修改对象内容 → 调用方能看到!
    }
}
// 返回 [1, 2]! (因为返回的是引用，finally 修改了对象内容)

finally 执行时机:

  ┌──────────────────────────┐
  │ try: return x            │
  │  → x 的值存入返回栈        │  ← 值拷贝(基本类型) 或引用(对象)
  │  → 执行 finally           │
  │  → 返回栈中的值            │  ← finally 修改 x 不影响基本类型
  └──────────────────────────┘    但通过引用修改对象内容可见

  最佳实践: 不要在 finally 中 return!

五、异常性能开销

// 异常创建开销
public class ExceptionPerf {
    public static void main(String[] args) {
        int loops = 1_000_000;

        // 1. 正常流程
        long start = System.nanoTime();
        for (int i = 0; i < loops; i++) {
            normalReturn(i);
        }
        long t1 = System.nanoTime() - start;

        // 2. 异常流程
        start = System.nanoTime();
        for (int i = 0; i < loops; i++) {
            exceptionFlow(i);
        }
        long t2 = System.nanoTime() - start;

        System.out.printf("正常: %dms, 异常: %dms, 差距: %.1fx\n",
            t1/1_000_000, t2/1_000_000, (double)t2/t1);
    }

    static int normalReturn(int i) { return i; }
    static int exceptionFlow(int i) {
        try {
            throw new RuntimeException();
        } catch (RuntimeException e) {
            return i;
        }
    }
}

异常性能开销来源:
  1. 异常对象创建: 填充调用栈 (Throwable.fillInStackTrace)
  2. 栈遍历: 获取当前线程的调用栈
  3. 异常抛出: JVM 查找匹配的 catch 块

  性能差异:
    正常流程: ~1ns/次
    异常流程: ~10-100μs/次 (取决于栈深度)
    差距: 1000-100000倍!

  优化建议:
  1. 异常只用于异常情况，不用于流程控制
  2. 高频路径避免异常 (如循环内)
  3. 可预见的条件判断用 if 代替 try-catch
  4. 重写 fillInStackTrace() 可以跳过栈填充 (性能优化)

// 优化: 跳过栈填充
public class FastException extends RuntimeException {
    @Override
    public synchronized Throwable fillInStackTrace() {
        return this; // 不填充栈，性能提升 10-100x
    }
}
// 代价: 无法获取异常栈信息
// 适用于: 高性能场景且不需要栈信息

六、异常处理最佳实践

// 1. 不要捕获大范围异常
try {
    // ...
} catch (Exception e) { // ❌ 太宽泛
    // 吞掉所有异常，包括 RuntimeException
}

// ✅ 捕获具体异常
try {
    // ...
} catch (IOException e) {
    log.error("IO失败", e);
}

// 2. 不要吞异常
try {
    // ...
} catch (Exception e) {
    // ❌ 吞异常，问题被隐藏
}

// ✅ 至少记录日志
try {
    // ...
} catch (Exception e) {
    log.error("操作失败", e);
    throw new BusinessException("操作失败", e); // 向上传播
}

// 3. 不要 catch RuntimeException
try {
    // ...
} catch (NullPointerException e) {
    // ❌ NPE 应该通过空检查预防
}
// ✅ 修复代码
if (obj != null) { obj.method(); }

// 4. finally 不要抛异常
try {
    // ...
} finally {
    resource.close(); // ❌ close 可能抛异常
}
// ✅ try-with-resources
try (Resource r = new Resource()) {
    // ...
}

// 5. 异常信息要有意义
throw new IllegalArgumentException("参数错误"); // ❌ 不明确
throw new IllegalArgumentException("age不能为负数: " + age); // ✅ 明确

七、常见面试追问

Q1：Error 和 Exception 的区别？

Error 是系统级错误（OOM、StackOverflow），程序无法恢复，不应捕获。Exception 是程序级错误，可以捕获处理。两者都继承自 Throwable。

Q2：throw 和 throws 的区别？

• throw: 抛出一个异常实例，throw new RuntimeException()
• throws: 声明方法可能抛出的异常，void method() throws IOException

Q3：try-with-resources 编译后是什么？

编译器会生成 try-finally 结构，在 finally 中调用 close()。如果 close() 也抛异常，原始异常优先，close 的异常通过 addSuppressed 附加。多个资源按声明逆序关闭。

Q4：异常是否影响性能？

异常对象创建时需要填充调用栈（fillInStackTrace），开销很大（10-100μs）。正常路径不应使用异常做流程控制。如果异常仅用于异常情况，性能影响可忽略。

Q5：OOME 可以被 catch 吗？

技术上可以，但不建议。OOME 表示堆已满，catch 后继续运行可能导致更严重的问题（数据不一致）。应该让 JVM 退出并分析 heap dump。

八、总结

异常体系核心:

  分类:
    Error → 系统错误，不捕获
    RuntimeException → 编程错误，修复代码
    Checked Exception → 外部问题，捕获处理

  最佳实践:
    ├── 用 try-with-resources 管理资源
    ├── 捕获具体异常，不要 catch Exception
    ├── 不要吞异常，至少记录日志
    ├── 异常链保留根因
    ├── finally 不要 return/throw
    └── 异常不用于流程控制

  争议:
    受检异常 → Java 独有设计，越来越不受欢迎
    趋势 → 非受检异常 + 函数式返回 (Optional/Either)

异常处理的本质是 在错误发生时提供清晰的诊断信息和优雅的恢复策略。理解异常体系的设计意图，才能在面试和实战中正确使用。