Java异常的层次结构与常见异常类

Java异常体系以Throwable为根，分为Error（不捕获）和Exception；Exception又分RuntimeException（非受检，如NullPointerException）和受检异常（如IOException，必须声明或捕获）。

Java异常体系是 Throwable 为根的树状结构，所有异常必须继承它；不继承 Throwable 的类哪怕名字带“Exception”，也不是合法异常。

Throwable 的两个直接子类：Error 和 Exception

Error 表示 JVM 无法恢复的严重问题（如 OutOfMemoryError、StackOverflowError），程序一般不应捕获或处理；Exception 才是开发者真正要面对的异常主体。

关键区别在于：Error 不强制要求声明或捕获，而 Exception 分为两类：

• RuntimeException 及其子类：运行时异常，编译器不检查（un-checked），比如 NullPointerException、ArrayIndexOutOfBoundsException
• 其他 Exception 子类（如 IOException、SQLException）：受检异常（checked），方法签名必须用 throws 声明，或在调用处用 try-catch 处理

常见的 RuntimeException 子类及典型触发场景

这些异常多数源于编程疏漏，不抛出具体堆栈也常能从代码逻辑中推断：

立即学习“Java免费学习笔记（深入）”；

• NullPointerException：调用 null 引用的实例方法、访问字段、数组长度等
• ArrayIndexOutOfBoundsException：下标 或 >= array.length
• ClassCastException：非法强转，如 (String) new Object()
• IllegalArgumentException：传入方法的参数明显不合逻辑（如 Thread.sleep(-1)）
• ConcurrentModificationException：遍历集合时被其他线程或同一线程的迭代器外操作修改了结构

注意：RuntimeException 虽不强制处理，但生产环境应尽量避免——它们反映的是可预防的代码缺陷，而非外部不确定性。

受检异常（Checked Exception）为什么必须显式处理？

设计意图是让开发者「正视不可控外部因素」：文件可能不存在、网络可能超时、数据库连接可能中断。JVM 强制你直面这些可能性，而不是静默忽略。

常见受检异常包括：

• IOException：读写文件、网络流、序列化失败
• SQLException：SQL 执行错误、连接失效、事务冲突
• ClassNotFoundException：反射时类名拼错或类未加载
• InterruptedException：线程被中断且当前方法声明抛出该异常（如 Thread.sleep()）

容易踩的坑：

• 用空 catch 吞掉受检异常（如 catch (IOException e) {}），等于放弃错误反馈
• 在 lambda 表达式中抛出受检异常却没用 try-catch 包裹，导致编译失败（函数式接口方法通常不声明 throws）
• 把 IOException 直接包装成 RuntimeException 后向上抛，掩盖了原始异常类型和上下文

自定义异常该怎么继承？选 RuntimeException 还是 Exception？

取决于你希望调用方是否「被迫处理」：

• 如果异常代表业务规则失败（如余额不足、状态非法），且调用方本就应该做决策（拒绝请求 / 降级 / 提示用户），推荐继承 RuntimeException —— 避免污染接口契约
• 如果异常代表必须响应的外部故障（如支付网关暂时不可用），且上层有统一重试/熔断机制，可继承 Exception，强制调用链显式传递

无论哪种，都建议提供带 String message 和 Throwable cause 的构造函数，并在必要时重写 getMessage() 以增强可读性。

一个最小可用的自定义运行时异常示例：

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

真正难的不是分清继承关系，而是判断某个异常该不该被“捕获并吞掉”、该不该“转换语义后重抛”、或者该不该“记录后继续传播”。这需要结合上下文，而不是查类图就能决定的。