Java异常体系必须严格遵循Throwable→Exception/Error双轨结构；需根据业务语义选择继承Exception（可预期、须显式处理的失败）或RuntimeException（编程错误），禁直接继承Throwable，且RuntimeException子类须防误吞。
Java 中异常类继承体系不是用来“设计新异常”的自由画布，而是必须严格遵循 Throwable → Exception / Error 的双轨结构；你决定的不是“要不要继承”，而是“继承谁”以及“是否检查”。
什么时候必须继承 Exception 而不是 RuntimeException
当异常代表**可预期、调用方理应显式处理的业务失败场景**时，必须继承 Exception（即受检异常）。JVM 会强制编译器要求 try-catch 或 throws，避免调用方忽略关键恢复逻辑。
- 典型场景：文件不存在（
FileNotFoundException）、网络连接超时（自定义NetworkTimeoutException）、数据库约束冲突（SQLException子类） - 反例：空指针、数组越界——这些是编程错误，应继承
RuntimeException，不强制上层处理 - 注意：继承
Exception后，所有构造函数必须显式调用super(...)，否则编译报错
为什么自定义异常通常不该直接继承 Throwable
直接继承 Throwable 会绕过 Java 异常分类语义，导致行为不可预测：既不会被 catch (Exception e) 捕获，也不属于 Error（JVM 不会终止线程），更无法被主流框架（如 Spring 的 @ExceptionHandler）识别为业务异常。
- 真实后果：日志中只显示
java.lang.Throwable，堆栈无上下文，监控系统无法归类 - 正确做法：99% 场景下，选
Exception（需检查）或RuntimeException（不检查）作为父类 - 唯一例外：极少数底层框架（如 JVM 内部调试器）才可能直接扩展
Throwable，业务代码禁止效仿
RuntimeException 子类如何避免被误吞
不检查 ≠ 不重要。很多 RuntimeException 子类（如自定义 ValidationException）实际承载关键业务语义，但因不强制捕获，极易在中间层被空 catch 吞掉或被 catch (Exception e) 模糊处理。
立即学习“Java免费学习笔记（深入）”；
- 命名提示：用
...Exception结尾（别用...Error），明确表示这是业务异常而非系统崩溃 - 日志强化：在构造函数里主动打
WARN级日志，或覆写printStackTrace()加入 traceId - 框架集成：Spring 中用
@ControllerAdvice统一捕获，避免散落在各处的try-catch - 测试覆盖：单元测试必须包含抛出该异常的路径，否则上线后才发现被静默吞掉
真正难的不是“怎么写继承”，而是判断哪个异常该检查、哪个该运行时抛、哪个该被全局拦截——这取决于调用契约是否稳定，而不是类名里有没有 “Checked” 字样。
