Error是JVM在系统级资源崩溃（如OOM、栈溢出）或环境失效时主动抛出的不可恢复错误；Exception是JVM执行字节码时因程序行为越界（如空指针、数组越界）触发的可处理异常。
Java中区分Error与Exception，关键不在“怎么写catch”，而在于理解它们被抛出的底层动因和JVM的响应逻辑。两者同为Throwable子类，但触发源头、发生时机和JVM处置策略完全不同。
触发源头：谁在抛？为什么抛？
Error由JVM自身在系统级资源崩溃或运行环境失效时主动抛出，不经过用户代码逻辑。比如：
- OutOfMemoryError：JVM在尝试分配对象时，发现堆/元空间/直接内存已无可用块，且GC无法回收足够空间，直接终止当前线程并抛出；
- StackOverflowError：方法调用栈深度超过-Xss设定阈值，JVM检测到栈帧无法压入，立即中断执行流；
- NoClassDefFoundError：类加载器在链接阶段（如准备或解析）发现依赖类缺失或静态初始化失败，不是编译期报错，而是运行时JVM加载机制卡死。
Exception则由JVM在执行字节码指令过程中，根据语义规则检测到非法状态后触发，本质是程序行为越界：
- NullPointerException：执行getfield/putfield等指令时，操作数栈顶引用为null，JVM按规范抛出；
- ArrayIndexOutOfBoundsException：执行aaload/iarray等数组访问指令时，索引值
- IOException：底层native方法（如read0）调用操作系统返回-1或EAGAIN，Java层封装为受检异常向上透出。
发生时机：编译期、运行期还是加载期？
Checked Exception（如SQLException）的强制处理要求，源于javac在编译阶段对方法签名中throws声明与实际调用链的静态分析——它不关心运行时是否真会发生，只确保语法层面有兜底路径。
立即学习“Java免费学习笔记（深入）”；
Error完全绕过编译检查，因为它的出现意味着JVM执行基础已瓦解。javac不会、也无法预判内存是否耗尽、栈是否溢出，这些判断全部推迟到运行时由HotSpot虚拟机实时监控。
RuntimeException虽属Exception分支，但其触发时机与Error更接近：都是JVM在解释/执行字节码瞬间检测到语义违规，属于运行期即时判定，不依赖外部I/O或用户输入。
JVM处置策略：能否继续安全执行？
当Error发生时，JVM会立即冻结当前线程的执行上下文，不保证锁释放、资源清理或finally块执行。例如OutOfMemoryError可能发生在finalize()调用中途，导致对象残留。此时JVM认为整个堆处于不可信状态，继续执行风险远大于终止。
Exception则被设计为可中断-恢复模型：try块中抛出异常后，JVM会按栈帧逐层回退，执行对应catch块，并保障同一try内的finally（若存在）一定执行——这是JVM规范明确保证的语义，也是程序能稳定容错的基础。
一个典型对比：捕获NullPointerException后，局部变量、堆对象、锁状态仍可控；而捕获OutOfMemoryError后，new Object()可能再次失败，synchronized块可能死锁，甚至System.out.println()都因字符串构造失败而二次抛异常。
自定义类型该继承谁？看责任边界
如果新类型代表业务流程必须显式应对的问题（如支付超时需降级），继承Exception，让编译器强制调用方处理；
如果新类型用于标记代码逻辑缺陷（如传入负数ID调用查询接口），继承RuntimeException，靠单元测试和静态扫描提前暴露；
永远不要继承Error——你的应用无权模拟JVM崩溃。强行继承只会混淆监控指标（把业务错误误报为系统故障），也违背Java异常体系的设计契约。
