梳理Spring Boot中三种异常处理

在 Spring Boot 中处理异常确实有多个方式，比如使用 @ControllerAdvice、 BasicErrorController、HandlerExceptionResolver等。不同方式适合不同的场景，下面是对这些方式的分析以及如何选择的建议：

🧩 1. @ControllerAdvice + @ExceptionHandler（推荐使用）

适用场景：
• 适合全局或局部地处理控制器抛出的异常。
• 适合为 REST 接口返回统一的异常结构（如 JSON）。

优点：
• 使用简单，语义明确。
• 可细粒度控制不同异常的处理逻辑。
• 与 Spring MVC 集成紧密，配合@ResponseStatus等注解效果更好。

示例：

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    public ErrorResponse handleNotFound(ResourceNotFoundException ex) {
        return new ErrorResponse("NOT_FOUND", ex.getMessage());
    }

    @ExceptionHandler(Exception.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    public ErrorResponse handleException(Exception ex) {
        return new ErrorResponse("INTERNAL_ERROR", "Unexpected error occurred");
    }
}

🧩 2. 自定义 BasicErrorController

适用场景：
• 需要完全控制 Spring Boot 默认错误响应行为时。
• 通常用于构建统一错误页面（HTML）或更底层的 JSON 错误处理逻辑。

优点：
• 可以替换 Spring Boot 默认的 /error 映射逻辑。
• 对 WebMvc + REST + WebFlux 一致性要求高时有用。

缺点：
• 实现复杂，通常不建议自定义它，除非你确实不满意 Spring Boot 提供的默认行为。

备注：
• Spring Boot 默认的错误信息来自 DefaultErrorAttributes 和 BasicErrorController。

🧩 3. HandlerExceptionResolver（低级机制）

适用场景：
• 需要低级别控制异常解析过程，比如处理过滤器/拦截器中抛出的异常。
• 不推荐用于日常业务异常处理。

优点：
• 可用于特殊场景，如非 MVC 层的异常处理。

缺点：
• 更底层、侵入性大、可维护性差。

✅ 选择建议总结

总得来说，如果是前后端分离的项目则选择@ControllerAdvice，如果是需要返回HTML错误页面选择BasicErrorController，除非有更底层的异常处理就选择HandlerExceptionResolver，但一般不建议使用。