应根据异常责任主体选择继承Exception或RuntimeException：外部环境不确定性导致的需调用方处理的异常继承Exception；程序逻辑缺陷或非法输入等内部问题继承RuntimeException。
继承 Exception 意味着必须显式处理
Java 中所有继承自 Exception（但不包括 RuntimeException 及其子类）的异常都属于「检查型异常（checked exception）」。编译器会强制要求你处理它：要么用 try-catch 捕获，要么在方法签名中用 throws 声明。
典型例子是 IOException、SQLException —— 它们代表外部环境可能出问题（如文件不存在、网络断开），设计上希望调用方意识到并决策如何应对。
- 如果你写了一个方法抛出
MyBusinessException extends Exception，所有调用它的代码都会编译失败，除非加try或throws - 过度使用会导致大量模板式
try-catch，尤其在底层工具类中，反而掩盖真正需要关注的错误分支 - 不适合封装逻辑错误（比如参数为空、状态非法），因为这类问题本该在开发/测试阶段暴露，而非留到运行时靠 try 去兜底
继承 RuntimeException 表示可不捕获，由 JVM 处理
RuntimeException 及其子类是「非检查型异常（unchecked exception）」，编译器不管——你可以选择捕获，也可以放任它向上冒泡甚至终止线程。
常见如
NullPointerException、IllegalArgumentException、ArrayIndexOutOfBoundsException，它们反映的是程序逻辑缺陷或非法输入，不是外部不确定性导致的。
- 自定义异常如
InvalidOrderStateException extends RuntimeException，适合用于业务规则校验失败（例如“已发货的订单不能取消”） - 这类异常一般不建议在 service 层
catch后吞掉或转成 success 返回，而应让外层统一拦截（如 Spring 的@ExceptionHandler）记录日志并返回友好提示 - 注意：
RuntimeException构造函数不强制传cause，但强烈建议在包装其他异常时调用super(message, cause)，否则原始堆栈会丢失
选哪个？关键看「谁该为这个异常负责」
这不是语法问题，而是 API 设计契约问题。决定依据不是“严重程度”，而是“异常是否属于调用方必须预期并响应的场景”。
- 如果异常源于外部系统（数据库、HTTP 服务、文件 IO），且调用方有合理手段恢复（重试、降级、提示用户重选路径），就继承
Exception - 如果异常源于调用方传参错误、状态误用、或内部逻辑矛盾（比如 switch 缺少 default 分支却走到不该走的 case），就继承
RuntimeException - Spring 生态中绝大多数自定义业务异常都应继承
RuntimeException；JDBC 相关操作仍需面对SQLException这类 checked 异常，但 Spring JDBC 已将其转为 unchecked 的DataAccessException层次
一个容易被忽略的细节：throws 声明对 RuntimeException 无效
即使你在方法签名里写了 throws MyRuntimeException，编译器也不会强制调用方处理它。这行声明只是文档作用，提醒阅读代码的人“这里可能发生这个异常”。
public void processOrder(Order order) throws InvalidOrderStateException {
if (order.isShipped()) {
throw new InvalidOrderStateException("已发货订单不可取消");
}
// ...
}
上面的 throws 不影响编译，但 IDE 可能据此生成 JavaDoc，团队协作时仍有价值。真正起约束作用的，只有继承链是否落在 Exception 下且未被 RuntimeException 排除。
很多人卡在「到底要不要 throws」，其实重点不在写不写这一行，而在异常类型本身的设计意图是否清晰——一旦类型语义模糊，后续所有处理逻辑都会被动摇。
