Exception 和 Error 是 Throwable 的两个平级子类，无继承关系；Exception 表示程序可处理的异常，应捕获或声明，Error 表示 JVM 严重错误，不应捕获而应快速终止。
Exception 和 Error 完全不是“轻重之分”，而是“能不能管”的根本区别——前者是程序该处理的意外，后者是 JVM 已经快不行了的求救信号。
为什么 catch(Error e) 几乎总是错的
因为 Error（如 OutOfMemoryError、StackOverflowError）发生时，JVM 往往已处于不可信状态：线程栈可能损坏、内存分配失败、甚至日志输出都可能卡住。此时捕获它并继续执行业务逻辑，大概率引发更隐蔽的崩溃或数据错乱。
- 你写
catch (StackOverflowError e)后调用System.out.println()，这个打印本身可能又触发一次栈溢出 -
catch (OutOfMemoryError e)之后试图 new 一个对象做“优雅降级”，结果直接 OOM 再次抛出 - 监控系统除外：只有在主入口（如 Spring Boot 的
SpringApplicationRunListener）或 APM 埋点中，才可捕获Error仅用于记录堆栈 +System.exit(1)快速终止
Exception 分两类，处理方式天差地别
编译器只强制你管 Checked Exception（比如 IOException、SQLException），而 RuntimeException 子类（如 NullPointerException、IllegalArgumentException）虽能 catch，但真正靠谱的做法是提前预防。
-
FileNotFoundException：必须try-catch或throws，否则编译不过 -
NullPointerException：不强制捕获，应靠判空、Optional、断言等手段在源头规避 - 别为了“看起来健壮”而在每个方法里套
try-catch (Exception e)——这会掩盖真实问题，且吞掉本该暴露的RuntimeException
继承结构决定你永远抓不到 Error
Exception 和 Error 是 Throwable 的两个平级子类，没有父子关系。这意味着：catch (Exception e) 永远捕获不到 OutOfMemoryError，哪怕你写了也白写。
立即学习“Java免费学习笔记（深入）”；
try {
// 触发 OOM 的代码，例如不断创建大数组
List list = new ArrayList<>();
while (true) {
list.add(new byte[1024 * 1024]);
}
} catch (Exception e) {
// ❌ 这里进不来，OOM 是 Error，不是 Exception
System.err.println("caught exception");
} catch (Error e) {
// ✅ 只有这里能捕获，但如前所述，不该这么做
System.err.println("caught error: " + e);
} 自定义异常千万别继承 Error
所有业务异常都应该继承 Exception（检查型）或 RuntimeException（非检查型）。继承 Error 不仅语义错误，还会导致调用方完全无法感知——编译器不提醒，IDE 不提示，线上出了问题连告警都难触发。
- 正确：
class UserNotFoundException extends RuntimeException - 错误：
class UserNotFoundException extends Error（这会让调用方误以为是 JVM 崩溃） - 检查型异常适合必须由上层决策的场景，比如支付失败后要不要重试；非检查型更适合参数非法、状态冲突等开发阶段就该发现的问题
最常被忽略的一点：很多团队把 NoClassDefFoundError 当成类没引入，其实它常是静态初始化块抛异常后的连锁反应——真正根因藏在 Throwable.getCause() 里，而 Error 通常没有有效 cause，查起来更费劲。
