java异常不该承载业务含义。异常本质是控制流中断机制，仅适用于不可恢复的非预期错误（如nullpointerexception、ioexception等），业务状态应通过返回值（如orderresult）显式表达，以降低维护成本、提升可测性与可扩展性。
Java异常该不该承载业务含义
不该。异常在Java中本质是控制流中断机制，不是业务状态表达载体。把 OrderAlreadyPaidException 这类名字当“业务返回值”用，等于把错误处理逻辑和领域规则混在一起——后续加个新状态（比如“已退款中”）就得新增异常类、改所有 catch 分支、补测试用例，维护成本指数上升。
哪些场景下用异常确实合理
仅限不可恢复、非预期、外部依赖失常或违反基础契约的情况：
-
NullPointerException：传了null给明确要求非空的参数（如Objects.requireNonNull(id, "id must not be null")） -
IllegalArgumentException：参数语义非法（如传age = -5给setAge(int)） -
IOException：文件读写失败、网络超时、数据库连接断开等外部资源异常 -
SQLException：SQL语法错、唯一键冲突、事务隔离导致的死锁回滚
这些异常不表示“业务分支”，而表示“当前操作无法继续执行”。它们该被上层捕获并转为用户可理解提示，或触发重试/降级，而不是被业务代码 if (e instanceof XxxException) 判断后走不同流程。
替代方案：用返回值或状态对象表达业务流转
推荐用不可变值对象封装结果，例如：
立即学习“Java免费学习笔记（深入）”；
public record OrderResult(OrderStatus status, String message, Order order) {}
// 调用方：
OrderResult result = orderService.pay(orderId);
if (result.status() == OrderStatus.PAID) {
sendReceipt(result.order());
} else if (result.status() == OrderStatus.ALREADY_PAID) {
log.warn("Duplicate payment attempt: {}", orderId);
}
优势明显：
- 调用方无需
try/catch，避免强制异常处理污染主路径 - 状态可枚举、可扩展（新增
REFUNDING只需加枚举值，不改异常体系） - 便于单元测试（直接 assert 返回值，不用 mock 异常抛出）
- 与 Spring Web 的
@ResponseStatus或响应体结构天然对齐
框架层异常如何与业务解耦
Spring MVC 等框架默认把未捕获异常转成 HTTP 错误码，但别让业务代码直接 throw ResponseStatusException(HttpStatus.CONFLICT, "已支付")。正确做法是：
- 业务层统一返回
Result<t></t>或类似结构 - Web 层用
@ControllerAdvice+@ExceptionHandler做集中转换：
→ 捕获IllegalArgumentException→ 400
→ 捕获自定义ResourceNotFoundException→ 404
→ 其他未预期异常 → 500 + 日志 - 真正需要“业务异常语义”的地方（如风控拦截），用
throw new BusinessException("余额不足", ErrorCode.INSUFFICIENT_BALANCE)，且该异常**不被业务方法 catch 处理**，只作为信号透传到统一异常处理器
关键点在于：异常类型只负责分类，不参与决策；业务分支必须由显式返回值驱动。否则你写的不是 Java，是披着 Java 外壳的状态机。
