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) 模糊处理。
