继承 RuntimeException 可创建非受检异常，调用方无需强制处理，适用于业务校验等逻辑错误；需提供三种构造器并按场景细分异常类型，避免将可预期外部故障误设为非受检异常。
在 Java 中，自定义异常继承 RuntimeException 是实现非受检异常（unchecked exception）最直接的方式。这样做的核心好处是：调用方无需强制处理（try-catch 或 throws），异常可自然向上抛出，简化错误传播逻辑，尤其适合业务校验、参数非法等程序逻辑错误场景。
为什么继承 RuntimeException 能避免编译检查
RuntimeException 及其子类属于“非受检异常”，Java 编译器不会强制要求捕获或声明。与之相对，继承 Exception（且不继承 RuntimeException）会成为“受检异常”（checked exception），调用处必须显式处理，否则编译失败。
因此，只要你的异常表示的是「本不该发生、应通过修复代码避免」的问题（如 ID 为空、状态非法、配置缺失），就适合设计为 RuntimeException 的子类。
标准写法：提供多种构造器以支持灵活使用
一个实用的自定义运行时异常，建议至少提供以下三个构造器：
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 仅传入错误消息：
public BusinessException(String message) - 传入消息 + 原始异常（用于链式异常封装）：
public BusinessException(String message, Throwable cause) - 仅传入原始异常（快速包装）：
public BusinessException(Throwable cause)
示例：
public class BusinessException extends RuntimeException {
public BusinessException(String message) {
super(message);
}
public BusinessException(String message, Throwable cause) {
super(message, cause);
}
public BusinessException(Throwable cause) {
super(cause);
}
}
配合业务分层使用，提升可读性与定位效率
实际项目中，可按模块或错误类型进一步细分异常，例如：
-
ParamValidationException：专用于参数校验失败 -
ResourceNotFoundException：标识资源未查到（如用户不存在） -
BusinessLockException：并发操作冲突时抛出
这类命名明确的异常，在日志、监控或全局异常处理器（如 Spring 的 @ControllerAdvice）中能快速识别问题类别，无需解析消息字符串。
注意避免滥用：不是所有错误都该是非受检的
需警惕将本应被显式处理的异常（如远程服务暂时不可用、文件系统写入失败）也设计为 RuntimeException 子类。这类问题属于“可预期的外部故障”，更适合用受检异常或返回结果封装（如 Result<T>），让调用方决定重试、降级或提示用户。
简单判断原则：如果这个异常出现，说明当前代码逻辑有缺陷或输入明显违规，那就用 RuntimeException；如果它可能因环境波动而偶发，就别绕过编译检查。
