Java自定义异常通过分层语义化设计替代错误码，如UserNotFoundException（业务异常）和PaymentServiceUnavailableException（系统异常），含错误码、消息模板与上下文参数，Service层直接抛出，使方法签名更简洁。
Java 中自定义异常可以替代传统错误码返回，核心在于把“错误语义”从返回值中剥离，交由异常机制统一承载——不是简单地 throw 一个 Exception，而是通过分层设计、语义明确的异常类型，配合合理的抛出与捕获策略，让业务逻辑更干净、错误处理更可读、系统更易维护。
定义语义清晰的自定义异常类
避免泛用 RuntimeException 或笼统的 Exception。应按错误性质分类，例如：
-
业务异常（非系统故障）：如
UserNotFoundException、InsufficientBalanceException，继承RuntimeException，不强制上层 try-catch，表示“流程中预期可能发生的业务失败” -
系统异常（需干预或告警）：如
PaymentServiceUnavailableException，可继承Exception或带检查逻辑的运行时异常，用于封装外部依赖失败等需要明确处理的场景
每个异常类建议包含：唯一错误码（如 ERROR_USER_NOT_FOUND = "USER_001"）、可读消息模板、可选上下文参数（如 userId），便于日志记录和前端提示。
在 Service 层主动抛出，而非返回错误码
传统方式常在 service 方法中返回 Result<T> 或 Map<String, Object>，内含 code/message/data。改用异常后，方法签名回归纯粹语义：
立即学习“Java免费学习笔记（深入）”；
public Order createOrder(CreateOrderRequest request) {
User user = userRepo.findById(request.getUserId())
.orElseThrow(() -> new UserNotFoundException(request.getUserId()));
if (user.getBalance() < request.getAmount()) {
throw new InsufficientBalanceException(user.getId(), request.getAmount());
}
return orderRepo.save(new Order(request));
}
调用方无需判断 code == 200 才继续，逻辑直译业务规则，可读性显著提升。
全局异常处理器统一收敛响应
使用 @ControllerAdvice + @ExceptionHandler 拦截自定义异常，转换为标准 API 响应格式（如统一的 JSON 结构）：
- 对
UserNotFoundException返回 HTTP 404 +{"code":"USER_001","message":"用户不存在","data":null} - 对
InsufficientBalanceException返回 HTTP 400 + 对应错误码和提示 - 未捕获的其他异常默认转为 500，并记录堆栈（生产环境隐藏细节）
这样既保持 REST 接口契约稳定，又避免每个 Controller 重复写 error response 构造逻辑。
与 Spring Validation、事务、重试等机制自然协同
异常机制天然适配 Spring 生态：
-
@Valid校验失败自动抛MethodArgumentNotValidException，可被统一处理器捕获并转成业务友好的字段级错误 - 声明式事务（
@Transactional）默认在RuntimeException时回滚，业务异常直接触发一致性保障 - 配合
@Retryable可对特定异常（如网络超时类）自动重试，而业务异常（如参数错误）不重试，语义精准
错误码方式难以做到这种细粒度、声明式的控制流管理。
不复杂但容易忽略的是：自定义异常要真正发挥价值，必须配套建立错误码文档、统一日志埋点（如 MDC 记录 traceId + errorCode）、前端根据 code 做差异化提示——它是一套协作约定，不是单点技术替换。
