exception 表示可捕获、可处理、可恢复的异常，如 ioexception；error 表示 jvm 或底层严重故障，通常不可恢复，如 outofmemoryerror。
Error 和 Exception 都表示程序执行中出现了异常情况，但它们在设计意图和可恢复性上存在本质差异。
Exception：设计为可捕获、可处理、可恢复
Exception 是 Java 等语言中明确为“程序运行时可能出错，但调用方有能力应对”的情形而设。它分为检查型（Checked）和非检查型（Unchecked），但无论哪一类，都默认允许且鼓励开发者通过 try-catch 或 throws 主动干预。
- 例如：文件不存在（FileNotFoundException）、网络超时（IOException）、数组越界（ArrayIndexOutOfBoundsException）——这些场景下，程序通常能降级处理：重试、换路径、返回默认值、提示用户重试等。
- 关键点在于：抛出 Exception 的代码本身不假设系统已崩溃；调用栈上游仍有合理逻辑继续运转的空间。
- 即使 RuntimeException（如 NullPointerException），也常反映业务逻辑疏漏，修复后可完全恢复正常行为。
Error：代表严重故障，通常不可恢复
Error 描述的是 JVM 自身或底层环境发生的、超出应用程序控制能力的严重问题。它不是给业务代码“处理”的，而是提示开发者：当前执行上下文已不可信，继续运行可能引发更不可控后果。
- 典型例子：OutOfMemoryError（堆/元空间耗尽）、StackOverflowError（递归过深或无限循环）、NoClassDefFoundError（类加载失败）——此时 JVM 可能已无法安全分配对象、执行方法或维持线程栈。
- 虽然语法上仍可用 catch 捕获 Error，但捕获后几乎无法做出有意义的恢复动作。强行“处理”往往掩盖问题，导致内存泄漏、数据不一致或静默失败。
- 正确做法是记录日志、触发监控告警，并尽快终止当前线程或服务实例，避免污染其他请求。
判断可恢复性的核心依据
不取决于异常名称或是否继承自 Throwable，而看两个实际约束：
- 资源可控性：出错是否由应用可管理的资源（如文件句柄、数据库连接、用户输入）引发？若是，大概率是 Exception。
- 状态一致性：异常发生后，当前线程及共享状态（如静态变量、缓存、数据库事务）是否仍处于可预测、可清理的状态？若否（如 OOM 后内存布局已紊乱），则属于 Error 范畴。
实践中需注意的灰色地带
某些框架或库会将本该定义为 Error 的问题包装成 Exception（如某些 RPC 框架把连接断开抛为自定义 Exception）。此时需结合错误码、日志堆栈和系统表现综合判断：
- 如果同一异常反复出现且伴随 CPU/内存飙升，优先按 Error 对待；
- 如果仅在特定输入下偶发，且重启线程后立即恢复，则更倾向 Exception；
- 永远不要在 catch (Exception e) 中吞掉未预期的 Error，除非你明确知道如何安全地隔离并清理其影响。
