Error 表示程序不应捕获也无法合理恢复的严重系统级问题，如 OutOfMemoryError；Exception 分为受检（如 IOException）和非受检（如 NullPointerException），用于可预期、可处理的异常场景。
Error 和 Exception 都继承自 Throwable，但设计意图和使用场景完全不同：前者表示程序本不应捕获、也无法合理恢复的严重问题；后者代表可预期、可处理的异常情况。
语义与设计定位不同
Error 是 JVM 层面或系统级故障的信号，比如内存耗尽（OutOfMemoryError）、栈溢出（StackOverflowError）、类加载失败（NoClassDefFoundError）。它们不是程序逻辑错误，而是运行环境崩溃或资源枯竭的体现。Java 规范明确建议：应用程序**不应当捕获 Error**，更不应试图“恢复”它。
Exception 分为两类：
-
受检异常（Checked Exception）：如
IOException、SQLException，编译器强制要求处理（try-catch 或 throws）；反映外部可变因素（文件不存在、网络中断），属于业务流程中需显式应对的异常分支。 -
非受检异常（Unchecked Exception）：即
RuntimeException及其子类，如NullPointerException、ArrayIndexOutOfBoundsException，通常源于编程疏漏，编译器不强制处理，但应通过代码健壮性来预防。
Error 为什么“不可控”
Error 的不可控性不是指技术上无法 catch，而是指——即使你写了 catch (Error e)，也几乎无法做出有意义的响应：
立即学习“Java免费学习笔记（深入）”；
- JVM 状态可能已损坏（例如堆已彻底耗尽），继续执行风险极高；
- 多数 Error 没有可靠的恢复路径（你不能“释放一点内存”再继续运行）；
- 捕获后若仍调用
e.printStackTrace()并吞掉，反而掩盖了系统级故障，延误运维干预； - 某些 Error（如
VirtualMachineError子类）发生时，JVM 可能已进入不稳定状态，连日志输出都可能失败。
实际开发中该怎么做
对 Error：监控优先，防御次之，捕获慎之。
- 用 JVM 参数（如
-XX:+HeapDumpOnOutOfMemoryError）自动导出堆快照，配合 Prometheus + Grafana 做内存/线程等指标告警； - 在应用启动入口（如 Spring Boot 的
SpringApplicationRunListener）或顶层线程未捕获异常处理器中，记录 Error 并触发快速退出或服务降级； - 避免在业务方法中写
catch (Error e)—— 除非你在写容器、框架或 JVM 工具类，且有明确的兜底策略（如安全关闭连接、保存关键状态）； - 区分
Error和Exception的日志级别：Error 记为ERROR或FATAL，并确保日志落地（不要只打在控制台）。
一个容易混淆的点：NoClassDefFoundError vs ClassNotFoundException
虽然名字相似，但本质不同：
-
ClassNotFoundException是 Exception（受检），发生在类加载器显式调用Class.forName()找不到类时，可被捕获并处理； -
NoClassDefFoundError是 Error，表示类在编译期存在，但运行期因静态初始化失败、JAR 缺失或类加载器隔离等原因，导致 JVM 在首次主动使用该类时无法找到其定义 —— 这是环境一致性被破坏的信号，属于部署或依赖问题，不是代码能“处理”的。
