java通用异常基类应继承runtimeexception，命名为baseexception或businessexception，仅提供标准构造方法、errorcode等通用字段，不覆盖getmessage；按业务域分层命名子类，并配合@controlleradvice统一响应。
Java 中设计通用基类异常，核心是明确用途、控制粒度、保持轻量。不建议虚构或套用不存在的基类（比如 ApplicationException），它既不是 JDK 也不是 Spring 的标准类型，强行继承会导致编译失败。
选对父类：RuntimeExcepion 还是 Exception？
绝大多数业务场景应以 RuntimeException 为父类：
- 避免在每个 service 方法上堆砌
throws声明，降低调用成本 - 符合 Spring Boot 默认异常处理风格（如
@ControllerAdvice自动捕获所有RuntimeException子类） - 业务异常本质是“不该发生但发生了”，属于逻辑层面问题，不是必须恢复的系统资源类错误
- 若真需强制处理（如支付回调超时重试策略必须显式 catch），再单独定义
extends Exception的受检异常，不作为通用基类
定义一个精简、可扩展的 BaseException
推荐命名为 BaseException 或 BusinessException，继承 RuntimeException，只做三件事：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 提供标准构造方法：无参、
String message、String message, Throwable cause—— 必须显式调用super(...)，否则丢失堆栈 - 封装通用字段：如
errorCode（int 或 String 类型）、timestamp（可选），不建议加userIdorderId等业务字段（易引发序列化/职责混乱问题） - 不重写
getMessage()或getCause()—— 日志和调试依赖原始信息，覆盖会掩盖真实原因
分层命名与继承结构要语义清晰
基类只是起点，真正价值在分层细化：
- 按业务域建一级子类：如
UserException、OrderException、PaymentException - 按具体场景建二级异常：如
UserNotFoundException extends UserException、InsufficientBalanceException extends PaymentException - 类名体现“什么错了”，而非“怎么错的”：用
OrderAlreadyShippedException，不用UpdateOrderStatusFailedException
配合全局处理器统一响应
有了基类，必须搭配 @ControllerAdvice 才能发挥价值：
- 捕获
BaseException及其所有子类，返回标准化 JSON（含code、msg、timestamp） - 对
IllegalArgumentException、NullPointerException等系统异常做兜底记录，但不暴露堆栈给前端 - 用
@ResponseStatus为特定异常指定 HTTP 状态码，例如UserNotFoundException → 404
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
