checked异常编译期强制处理，需try-catch或throws；runtime异常编译期不检查，反映逻辑缺陷。前者应对外部不确定性，后者暴露程序错误，应通过防御性编程避免。
受检异常（Checked Exception）和运行时异常（Runtime Exception）的核心差异不在“要不要处理”，而在于编译器是否强制你面对它——一个必须立刻回应，另一个可以暂且搁置，但不能视而不见。
编译期是否强制干预
这是最直观的分水岭：
- Checked异常（如IOException、SQLException）在编译阶段就被检查。只要代码里可能抛出它，就必须二选一：用
try-catch捕获，或在方法签名加throws声明；否则编译直接失败。 - Runtime异常（如NullPointerException、ArrayIndexOutOfBoundsException）编译器完全放行。写
int a = 10 / 0;能顺利通过编译，但运行时一定崩溃。
异常来源与设计意图不同
它们代表两类性质不同的问题：
- Checked异常通常源于外部不确定性：文件被删除、网络断开、数据库连接超时……这些不是代码写错了，而是环境不可控。Java要求你提前考虑恢复路径，比如重试、降级、提示用户。
- Runtime异常基本是程序逻辑缺陷的信号：访问了null对象、数组下标越界、类型强转失败……这些问题本应在开发阶段被发现和修复，而不是靠运行时捕获来掩盖。
实际编码中怎么应对
知道区别后，关键是怎么用：
- 对Checked异常，别一股脑全
throws往上推。优先判断能否就地恢复：读文件失败，试试默认配置；连不上DB，查查缓存有没有旧数据。 - 对Runtime异常，少用
catch (RuntimeException e)大包抄。更有效的是防御性编程：调用前判空、集合操作前校验size、数学运算前检查除数。 - 自定义异常时，如果这个错误属于“业务上可预期但需干预”的情况（如余额不足、权限不足），继承
Exception；如果是“代码明显写错了才触发”的场景（如传入非法状态枚举），继承RuntimeException更合适。
