Java异常体系以Throwable为根,分为Error(系统级致命错误,不可处理)和Exception(可处理异常);Exception进一步分为受检异常(编译强制处理,如IOException)和非受检异常(继承自RuntimeException,编译不检查,如NullPointerException)。

Java 异常体系的核心在于Throwable,它是所有异常和错误的根类。从它出发,整个体系分成两条主线:Error 和 Exception。我们日常打交道、需要主动设计处理逻辑的,几乎全部落在 Exception 分支下;而它的进一步划分——受检异常(Checked Exception) 与 非受检异常(Unchecked Exception)——直接决定了代码能不能编译通过、要不要写 try-catch、该不该往上抛。
受检异常:编译器盯得紧,必须显式应对
受检异常指所有继承自 Exception 但不继承自 RuntimeException 的异常,比如 IOException、SQLException、ClassNotFoundException。它们代表的是程序**外部可预期但不可控的问题**,例如文件可能不存在、数据库连接可能中断、网络请求可能超时。
- 编译器强制要求:调用可能抛出这类异常的方法时,必须用 try-catch 捕获,或在方法签名中用 throws 声明抛出,否则编译失败
- 设计意图是推动开发者提前考虑恢复策略,比如重试、降级、提示用户等
- 典型场景:文件读写、JDBC 操作、反射加载类、序列化/反序列化
非受检异常:运行时才暴露,靠代码质量兜底
非受检异常包括 RuntimeException 及其子类(如 NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException),也包含 Error(如 OutOfMemoryError)。它们大多源于程序逻辑缺陷或 JVM 层面严重故障。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 编译器完全不干预:即使代码明显会空指针,也不报错,允许直接运行
- 通常不应捕获 Error,也不建议泛捕 RuntimeException——更应做的是修复 bug、加判空、校验参数、优化资源使用
- 例外情况:某些业务场景下可针对性捕获特定 RuntimeException(如解析 JSON 失败时捕获 JsonProcessingException,虽然它实际是 RuntimeException 子类)
关键区别一句话总结
是否继承自 RuntimeException 是分水岭:是 → 非受检,编译不管;否且是 Exception 子类 → 受检,编译强制处理。这个继承关系不是命名约定,而是 Java 编译器底层检查的硬规则。
立即学习“Java免费学习笔记(深入)”;
怎么用才合理
- 对受检异常:能当场解决就 try-catch(比如文件不存在时创建默认配置);不能处理就 throws 向上传递,别用空 catch 吞掉
- 对非受检异常:优先预防,比如操作前判 null、集合前 check size、数值运算前校验范围;避免用 try-catch 替代逻辑校验
- 自定义异常时,如果是业务上可预期且需调用方感知的失败(如“余额不足”“库存不够”),建议继承 Exception(受检);如果是流程中不该发生的逻辑错(如状态机非法流转),继承 RuntimeException(非受检)

















