在Java里异常是否属于业务逻辑_Java异常设计边界说明_技术教程

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) 判断后走不同流程。

替代方案：用返回值或状态对象表达业务流转

推荐用不可变值对象封装结果，例如：

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 或类似结构
Web 层用 @ControllerAdvice + @ExceptionHandler 做集中转换：
→ 捕获 IllegalArgument Exception → 400
→ 捕获自定义 ResourceNotFoundException → 404
→ 其他未预期异常 → 500 + 日志
真正需要“业务异常语义”的地方（如风控拦截），用 throw new BusinessException("余额不足", ErrorCode.INSUFFICIENT_BALANCE)，且该异常**不被业务方法 catch 处理**，只作为信号透传到统一异常处理器