如何处理BadRequestBodyException和ResourceNotFoundException？我的实现是否合理？

一、当前异常处理是否正确？ #

当前的异常处理在业务语义上是合理的，但存在规范和架构层面的不足：

• ResourceNotFoundException：通过orElseThrow在找不到客户时抛出，契合REST服务“资源不存在”的场景（对应HTTP 404状态码），这个处理逻辑没问题。
• BadRequestBodyException：在请求体必填字段为空时抛出，符合“请求参数无效”的场景（对应HTTP 400状态码），语义上正确，但缺少统一的异常处理机制——如果不在Web层或全局捕获这些异常，Spring容器会默认返回500内部错误，而非符合规范的400/404响应。

二、更优的实现方案 #

1. 用JSR-380注解替代手动参数校验 #

在Customer实体类的必填字段上添加校验注解，让Spring自动完成参数校验：

public class Customer {
    @NotBlank(message = "客户名称不能为空")
    private String customerName;
    
    @NotBlank(message = "客户类型不能为空")
    private String customerType;
    
    // 其他字段、getter/setter
}

Controller层方法参数添加@Valid触发校验：

@PutMapping("/customers/{id}")
public ResponseEntity<String> updateCustomer(@PathVariable String id, @Valid @RequestBody Customer customer) {
    customerService.updateCustomer(id, customer);
    return ResponseEntity.ok("Customer updated successfully.");
}

服务层去掉手动判断，专注业务逻辑：

@Override
public void updateCustomer(String id, Customer customer) throws ResourceNotFoundException {
    log.info("Updating customer.");
    Customer existingCustomer = customerRepository.findCustomerById(id)
            .orElseThrow(() -> new ResourceNotFoundException("Error: Customer not found for id - " + id));
    
    existingCustomer.setCustomerName(customer.getCustomerName());
    existingCustomer.setCustomerType(customer.getCustomerType());
    
    customerRepository.save(existingCustomer);
}

2. 全局异常处理统一响应格式 #

创建全局异常处理器，捕获校验异常和资源不存在异常，返回规范的HTTP状态码：

@ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<String> handleResourceNotFound(ResourceNotFoundException ex) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(ex.getMessage());
    }
    
    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<String> handleInvalidRequest(MethodArgumentNotValidException ex) {
        String errorMsg = ex.getBindingResult().getFieldErrors().stream()
                .map(FieldError::getDefaultMessage)
                .collect(Collectors.joining("; "));
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(errorMsg);
    }
}

3. 服务层与Web层解耦 #

服务层不要返回ResponseEntity，它属于Web层API，服务层应专注业务逻辑，返回void或业务对象，将响应构建的职责交给Controller层，符合分层架构的单一职责原则。

4. 优化异常信息管理 #

避免硬编码异常信息，将错误信息放在配置文件（如messages.properties）中，通过MessageSource获取，方便国际化和统一维护。

三、当前实现的优缺点 #

优点 #

• 逻辑简单直观，新手易理解和维护
• 明确区分“资源不存在”和“请求体无效”两种错误场景，语义清晰
• 完成核心的客户更新业务逻辑，能满足基础功能需求

缺点 #

• 手动参数校验扩展性差：新增必填字段时需修改if条件，代码冗余且易遗漏
• 服务层耦合Web层：返回ResponseEntity导致服务层依赖Spring Web组件，不符合分层设计，不利于复用和测试
• 异常处理不规范：缺少全局处理，未返回符合REST规范的HTTP状态码，前端无法正确识别错误类型
• 异常信息硬编码：不利于后续国际化和统一维护
• 校验范围有限：仅校验customerName和customerType，若有其他必填字段未覆盖，会导致无效请求进入业务逻辑

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