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,只做三件事:
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 提供标准构造方法:无参、
String message、String message, Throwable cause—— 必须显式调用super(...),否则丢失堆栈 - 封装通用字段:如
errorCode(int 或 String 类型)、timestamp(可选),不建议加userIdorderId等业务字段(易引发序列化/职责混乱问题) - 不重写
getMessage()或getCause()—— 日志和调试依赖原始信息,覆盖会掩盖真实原因
分层命名与继承结构要语义清晰
基类只是起点,真正价值在分层细化:
立即学习“Java免费学习笔记(深入)”;
- 按业务域建一级子类:如
UserException、OrderException、PaymentException - 按具体场景建二级异常:如
UserNotFoundException extends UserException、InsufficientBalanceException extends PaymentException - 类名体现“什么错了”,而非“怎么错的”:用
OrderAlreadyShippedException,不用UpdateOrderStatusFailedException
配合全局处理器统一响应
有了基类,必须搭配 @ControllerAdvice 才能发挥价值:
- 捕获
BaseException及其所有子类,返回标准化 JSON(含code、msg、timestamp) - 对
IllegalArgumentException、NullPointerException等系统异常做兜底记录,但不暴露堆栈给前端 - 用
@ResponseStatus为特定异常指定 HTTP 状态码,例如UserNotFoundException → 404

















