Java处理自定义业务异常的核心是抛出带错误码的BusinessException→由@ControllerAdvice全局捕获→统一转为Result响应体；需注意事务、异步、Filter等场景下异常传播失效问题，错误码应分段设计（如1001表示用户模块“用户不存在”），避免混用HTTP状态码。
Java 中处理自定义业务异常并返回统一错误码，核心是「抛出有含义的异常 → 拦截并转换为标准响应 → 前端可解析」。关键不在“怎么 throw”，而在于「异常如何被识别、捕获、映射成一致的 JSON 结构」。
定义业务异常类（带错误码和消息）
继承 RuntimeException，避免强制 try-catch；每个异常实例携带唯一错误码（如枚举或常量）、可读消息、可选扩展字段（如 requestId）：
示例：
public class BusinessException extends RuntimeException {
private final int code;
private final String message;
public BusinessException(ErrorCode errorCode) {
super(errorCode.getMessage());
this.code = errorCode.getCode();
this.message = errorCode.getMessage();
}
// getter 省略
}
配套定义错误码枚举：
public enum ErrorCode {
USER_NOT_FOUND(40001, "用户不存在"),
INSUFFICIENT_BALANCE(40002, "余额不足"),
ORDER_EXPIRED(40003, "订单已过期");
private final int code;
private final String message;
ErrorCode(int code, String message) {
this.code = code;
this.message = message;
}
// getter 省略
}
抛出时直接用：throw new BusinessException(ErrorCode.USER_NOT_FOUND);
全局异常处理器（@ControllerAdvice + @ExceptionHandler）
拦截所有控制器中抛出的 BusinessException，并统一包装为标准响应体（如 Result
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(BusinessException.class)
@ResponseBody
@ResponseStatus(HttpStatus.OK) // 业务异常通常不走 HTTP 4xx/5xx，保持 200 更利于前端判断
public Result<void> handleBusinessException(BusinessException e) {
return Result.fail(e.getCode(), e.getMessage());
}
// 可选：兜底处理其他未预期异常（如 NullPointerException）
@ExceptionHandler(Exception.class)
@ResponseBody
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
public Result<void> handleUnexpectedException(Exception e) {
log.error("系统未预期异常", e);
return Result.fail(50000, "服务内部错误");
}
}</void></void>
Result 结构示例：
public class Result<t> {
private int code;
private String message;
private T data;
public static <t> Result<t> fail(int code, String message) {
Result<t> r = new Result();
r.code = code;
r.message = message;
return r;
}
// success()、getter/setter 略
}</t></t></t></t>
确保异常能被正确捕获（注意事务与代理边界）
以下情况会导致 @ControllerAdvice 失效，需特别注意：
- Service 层抛出异常但没传播到 Controller：比如在 @Transactional 方法里吞掉了异常，或用了 try-catch 却没 re-throw
- 异步方法（@Async）中抛异常：默认不会进入全局异常处理器，需手动捕获或配置 AsyncUncaughtExceptionHandler
- Filter / Interceptor 中抛异常：早于 Spring MVC 生命周期，需单独处理（如在 doFilter 中 try-catch 并写响应）
- 参数校验失败（@Valid）：默认抛 MethodArgumentNotValidException，需额外加 @ExceptionHandler(MethodArgumentNotValidException.class) 映射为业务错误码
前端友好：错误码设计建议
错误码不是随意编号，推荐分段设计，便于定位问题类型：
- 前两位表示模块：如 10xx 用户模块、20xx 订单模块、30xx 支付模块
- 后两位表示具体错误：如 1001 用户不存在、1002 密码错误
- 避免使用 HTTP 状态码替代业务码：HTTP 404 表示资源未找到（网络层），而“用户不存在”是业务逻辑结果，应返回 200 + code=1001
- 预留通用码段：如 99xx 表示系统级异常（DB 连接失败、远程调用超时等）
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
