在开发过程中，如何在 Controller 层 处理错误是一个非常重要的问题。你是否应该直接抛出异常，还是应该返回一个友好的错误代码？这一决定不仅影响代码的可读性和维护性，还会影响到用户体验与系统的健壮性。今天，我们就来探讨一下这个问题，并给出最佳实践。

一、异常抛出 vs 返回友好的错误代码

1. 异常抛出：优点与缺点

抛出异常通常意味着发生了不正常的行为，或者出现了无法预料的错误。异常通常用于 严重错误 或 系统级别的错误，比如数据库连接失败、外部服务不可用等。

优点：

• 代码简洁：当异常抛出时，程序会自动跳转到 @ExceptionHandler 或全局异常处理器，让你不需要在每个 Controller 方法中重复写错误处理代码。
• 可控性强：通过异常机制，你可以有条件地捕获不同类型的错误，灵活地处理复杂的异常逻辑。
• 能够提供详细的错误信息：通过异常，你可以传递详细的错误信息（例如，出错的原因和堆栈追踪），帮助开发人员进行调试。

缺点：

• 不够友好：抛出异常通常是为了表达一种程序层面的“故障”或“中断”，但它对于普通用户来说可能并不直观。用户无法理解为什么某个操作失败了。
• 会导致事务回滚：如果使用 Spring 的事务管理，一旦抛出异常，默认情况下会触发事务回滚，可能导致数据库状态不一致。
• 影响性能：异常的捕获与处理是有开销的，尤其是在异常频繁发生的场景下，性能可能会受影响。

示例：抛出异常

@GetMapping("/user/{id}")
public User getUser(@PathVariable Long id) {
    User user = userService.findUserById(id);
    if (user == null) {
        throw new UserNotFoundException("用户未找到，ID：" + id);
    }
    return user;
}

2. 返回友好的错误代码：优点与缺点

与抛出异常不同，返回错误代码（或者一个结构化的错误响应）是一种更加“温和”的错误处理方式。它通常用于常见的 业务逻辑错误，比如参数验证失败、请求数据不合法等。

优点：

• 用户体验友好：通过返回清晰的错误信息和提示码，用户可以更直观地了解错误发生的原因，并采取适当的解决措施。
• 灵活性高：开发者可以自定义错误码，确保错误信息符合业务需求，而且能够细化到特定的业务场景。
• 减少性能损耗：返回错误信息比抛出异常的性能开销要小，因为无需通过异常机制进行回溯处理。

缺点：

• 代码冗余：需要在每个控制器方法中明确返回错误信息，增加了代码重复性。
• 错误信息不够详细：相比异常堆栈信息，返回的错误代码和消息可能无法提供充分的调试信息。

示例：返回错误代码

@GetMapping("/user/{id}")
public ResponseEntity<Object> getUser(@PathVariable Long id) {
    User user = userService.findUserById(id);
    if (user == null) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND)
                             .body(new ErrorResponse("USER_NOT_FOUND", "用户未找到，ID：" + id));
    }
    return ResponseEntity.ok(user);
}

ErrorResponse 类：

public class ErrorResponse {
    private String code;
    private String message;

    public ErrorResponse(String code, String message) {
        this.code = code;
        this.message = message;
    }
    // getters and setters
}

二、Controller 层处理错误的最佳实践

1. 不同类型的错误使用不同方式

• 业务逻辑错误：对于 常见的业务错误，如参数错误、用户未授权等，返回结构化的错误代码会更友好。比如：400 Bad Request、404 Not Found 等，配合合适的错误消息。
• 系统级错误：对于 无法预见的系统错误，如数据库连接失败、外部服务不可用等，抛出异常可能更合适，这样可以快速终止不正常的操作，避免不一致的状态。

示例：业务错误返回错误码

@PostMapping("/user")
public ResponseEntity<Object> createUser(@RequestBody User user) {
    if (user.getName() == null || user.getName().isEmpty()) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST)
                             .body(new ErrorResponse("USER_NAME_EMPTY", "用户名不能为空"));
    }
    userService.saveUser(user);
    return ResponseEntity.status(HttpStatus.CREATED).body(user);
}

示例：系统错误抛出异常

@GetMapping("/external")
public String getExternalData() {
    try {
        String data = externalService.getData();
        return data;
    } catch (ExternalServiceException e) {
        throw new RuntimeException("外部服务调用失败", e);
    }
}

2. 统一错误处理

无论是通过返回错误代码还是抛出异常，统一处理异常 是提升代码整洁性和用户体验的关键。Spring 提供了强大的全局异常处理功能（@ControllerAdvice），我们可以通过它来集中管理 Controller 层的异常。

全局异常处理示例

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(UserNotFoundException.class)
    public ResponseEntity<Object> handleUserNotFoundException(UserNotFoundException e) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND)
                             .body(new ErrorResponse("USER_NOT_FOUND", e.getMessage()));
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<Object> handleException(Exception e) {
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
                             .body(new ErrorResponse("INTERNAL_ERROR", "系统错误，请稍后再试"));
    }
}

这样，所有控制器中的异常就可以统一处理，避免了重复的错误处理逻辑。

三、总结：如何选择？

0. 业务错误： 如果是常见的业务问题，如用户输入不合法、数据不存在等，建议使用 返回错误代码 的方式，这样既能避免异常处理的开销，又能提供更加友好的错误信息给用户。
1. 系统错误： 对于 系统级错误，如外部服务故障、数据库问题等，使用 抛出异常 的方式更加合适。可以通过全局异常处理器统一捕获，并返回系统级错误信息。

最后，统一异常处理 和 结构化错误信息 是提高代码质量和用户体验的关键，选择适合的方式，使得代码更加健壮、可维护。