Java异常体系以Throwable为根，分为Error和Exception；Exception再分Checked（编译期强制处理，如IOException）和Unchecked（运行时无需声明，如NullPointerException）两类，兼顾健壮性与灵活性。

Java的异常体系以Throwable为根，分为Error和Exception两大分支；其中Exception又进一步划分为编译期强制检查的Checked异常和运行时无需声明的Unchecked异常。这种分层设计兼顾了程序健壮性与开发灵活性。

Checked异常：编译器强制你面对的问题

Checked异常继承自Exception但不继承RuntimeException，典型如IOException、SQLException。它们代表程序**本可预期且应主动处理**的外部问题（比如文件不存在、网络超时）。

• 方法若可能抛出Checked异常，必须显式声明throws，或在内部用try-catch捕获
• 调用方无法忽略——编译不通过，倒逼开发者思考“这个IO操作失败了怎么办？”
• 不是所有受检异常都值得保留：JDK 7后AutoCloseable配合try-with-resources已大幅简化资源管理，部分场景可考虑封装或转为Unchecked

Unchecked异常：程序逻辑缺陷或不可控的运行时错误

Unchecked异常包括RuntimeException及其子类（如NullPointerException、ArrayIndexOutOfBoundsException）以及Error（如OutOfMemoryError）。它们在编译期不强制处理，因为：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• RuntimeException多源于编程疏漏（空指针、越界），应靠测试和代码审查提前发现，而非靠try-catch掩盖
• Error属于JVM级严重故障，应用通常无法恢复，捕获也无实际意义
• 过度捕获RuntimeException反而模糊问题根源，比如对NullPointerException做空catch，等于隐藏bug

如何合理选择与设计自定义异常

新增异常类型时，核心判断依据是“调用方是否具备合理恢复能力”：

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

• 若异常由外部环境导致（如第三方API限流、配置文件缺失），且业务逻辑能降级或重试，应继承Exception，定义为Checked异常
• 若异常反映内部状态不一致（如参数校验失败、非法状态转移），应继承RuntimeException，让问题快速暴露
• 避免滥用Exception父类直接抛出；明确异常语义（如用InsufficientBalanceException而非泛化的BusinessException），便于上层精准处理

异常体系不是为了增加编码负担，而是用类型系统把“哪些错该被看见”“哪些错该被处理”显性化。用好Checked与Unchecked的边界，代码才既有防御力，又不失可读性。