自定义ResponseStatusException咨询：指定错误消息及方案合理性验证

当前实现的正确性分析 #

你的当前实现可以达成预期效果：当订单不存在时，会抛出自定义异常并返回404 NOT_FOUND状态码，以及你指定的错误消息Order does not exist，而非Spring默认的Not found。因为ResponseStatusException是Spring提供的异常类，会自动被框架处理并返回对应的状态码和消息，控制器层无需额外编写异常处理逻辑，这部分是有效的。

扩展性评估：不适用于未来多场景自定义异常需求 #

这个方案的局限性很明显，无法适配后续更多的业务异常场景：

• 你的RetailIn_APIException构造函数固定了状态码和错误消息，只能处理"订单不存在"这一种异常。后续要新增其他业务异常（比如"订单已取消"、"参数格式非法"）时，要么不断给这个类添加新的构造函数，要么新建多个类似的异常类，会导致代码臃肿、缺乏语义化区分。
• 直接继承ResponseStatusException虽然简单，但这类Spring通用异常没有业务语义，不利于团队协作中的代码可读性和维护性。

更具扩展性的优化方案 #

建议采用自定义业务异常基类+全局异常处理器的模式，既能满足当前需求，也能轻松扩展后续场景：

1. 定义业务异常基类

public class RetailInBusinessException extends RuntimeException {
    private final HttpStatus status;
    private final String message;

    public RetailInBusinessException(HttpStatus status, String message) {
        super(message);
        this.status = status;
        this.message = message;
    }

    // Getter方法
    public HttpStatus getStatus() {
        return status;
    }

    @Override
    public String getMessage() {
        return message;
    }
}

2. 针对具体业务场景创建异常类

每个业务异常对应一个类，语义清晰，方便扩展：

// 订单不存在异常
public class OrderNotFoundException extends RetailInBusinessException {
    public OrderNotFoundException() {
        super(HttpStatus.NOT_FOUND, "Order does not exist");
    }
}

// 后续可新增其他业务异常，比如：
public class OrderCancelledException extends RetailInBusinessException {
    public OrderCancelledException() {
        super(HttpStatus.BAD_REQUEST, "Order has been cancelled");
    }
}

3. 编写全局异常处理器

统一处理所有业务异常，避免重复代码：

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(RetailInBusinessException.class)
    public ResponseEntity<Map<String, Object>> handleBusinessException(RetailInBusinessException ex) {
        Map<String, Object> errorResponse = new HashMap<>();
        errorResponse.put("status_code", ex.getStatus().value());
        errorResponse.put("error_message", ex.getMessage());
        return new ResponseEntity<>(errorResponse, ex.getStatus());
    }
}

4. 修改Service与Controller层代码

// Service层
public Optional<ClientOrder> getOrderById(Long orderId) {
    return orderRepository.findById(orderId)
            .orElseThrow(OrderNotFoundException::new);
}

// Controller层：无需声明抛出异常，全局处理器会自动处理
@GetMapping("/{orderId}")
public ResponseEntity<ClientOrder> getOrderById(@PathVariable Long orderId) {
    ClientOrder order = orderService.getOrderById(orderId)
            .orElseThrow(OrderNotFoundException::new);
    return ResponseEntity.ok(order);
}

总结 #

当前实现能解决眼前的问题，但扩展性不足。改用自定义业务异常基类+全局异常处理器的模式后，代码结构更清晰，语义化更强，后续新增任何业务异常都只需创建对应的异常类即可，无需修改核心处理逻辑，完全适配未来的扩展需求。

内容的提问来源于stack exchange，提问作者redbeard