推荐继承 runtimeexception，因其属非检查异常，避免强制处理、契合事务回滚、便于统一拦截；业务异常本质是逻辑错误而非系统故障，无需编译器强制捕获。
Java中抛出自定义业务异常，核心是继承 RuntimeException（非检查异常）或 Exception（检查异常），并提供语义清晰的构造函数；绝大多数业务场景应选前者，避免强制调用方写 try-catch 或 throws，干扰主流程。
为什么推荐继承 RuntimeException 而不是 Exception
业务异常本质是「程序逻辑不该走到这里」，属于可预期但非系统故障的错误（如余额不足、参数非法、状态不匹配），不是 I/O 失败或空指针这类需要强制恢复的底层问题。
-
Exception子类会触发编译器强制要求处理（throws声明或try-catch），导致 Service 层大量模板代码，掩盖真实业务逻辑 -
RuntimeException子类由上层统一拦截（如 Spring 的@ControllerAdvice），保持各层方法签名干净 - Spring 默认只对
RuntimeException及其子类执行事务回滚，继承它能自然契合事务边界
如何设计一个实用的自定义业务异常类
关键不是堆砌功能，而是覆盖常见诉求：带错误码、支持国际化消息占位、保留原始异常上下文。
- 至少提供三个构造函数：
BusinessException(String code, String message)、BusinessException(String code, String message, Throwable cause)、BusinessException(String code, String message, Object... args) - 字段建议只保留
code（字符串，如"USER_NOT_FOUND"）和可选的data（用于透传额外信息，如失败的 userId） - 避免重写
getMessage()拼接逻辑——交给全局异常处理器做消息解析更灵活
public class BusinessException extends RuntimeException {
private final String code;
private final Map<String, Object> data = new HashMap<>();
<pre class='brush:java;toolbar:false;'>public BusinessException(String code, String message) {
super(message);
this.code = code;
}
public BusinessException(String code, String message, Throwable cause) {
super(message, cause);
this.code = code;
}
public BusinessException(String code, String message, Object... args) {
super(String.format(message, args));
this.code = code;
}
public String getCode() { return code; }
public Map<String, Object> getData() { return Collections.unmodifiableMap(data); }
public BusinessException withData(String key, Object value) {
this.data.put(key, value);
return this;
}}
立即学习“Java免费学习笔记（深入）”；
在 Spring Boot 中如何统一捕获并返回结构化响应
靠 @ControllerAdvice + @ExceptionHandler 拦截，但要注意两点：不要吞掉日志，不要把所有异常都塞进同一响应体。
- 对
BusinessException返回 200 状态码 + 标准业务错误体（含code、message、timestamp） - 对其他未预期异常（如
NullPointerException）返回 500，并记录完整堆栈（生产环境建议关掉堆栈详情） - 确保异常处理器方法不抛出新异常，否则会进入默认容器错误页
@RestControllerAdvice
public class GlobalExceptionHandler {
<pre class='brush:java;toolbar:false;'>@ExceptionHandler(BusinessException.class)
public ResponseEntity<ApiResponse> handleBusinessException(BusinessException e) {
log.warn("Business exception: {} - {}", e.getCode(), e.getMessage(), e);
return ResponseEntity.ok(ApiResponse.error(e.getCode(), e.getMessage(), e.getData()));
}
@ExceptionHandler(Exception.class)
public ResponseEntity<ApiResponse> handleUnexpectedException(Exception e) {
log.error("Unexpected error", e);
return ResponseEntity.status(500).body(ApiResponse.error("SYSTEM_ERROR", "服务暂时不可用"));
}}
立即学习“Java免费学习笔记（深入）”；
容易被忽略的细节
真正上线后踩坑最多的，往往不是类怎么写，而是怎么用。
- 别在 DAO 层抛
BusinessException——数据库查不到用户，不等于「业务不允许」，应由 Service 层根据上下文判断是否构成业务异常 - 错误码必须全局唯一且含义稳定，避免
"ORDER_CANCEL_FAILED"在不同模块代表不同语义 - 不要在异常消息里拼接敏感数据（如密码、身份证号），
withData()也需过滤 - 单元测试时，用
Assertions.assertThrows()检查异常类型和code字段，而不是只断言消息字符串
