Spring Boot全局异常处理的背后的故事

关注我的公众号：【编程朝花夕拾】，可获取首发内容。

01 引言

SpringBoot的全局异常处理已经被各大技术大牛讲烂了，使用@ControllerAdvice、@ExceptionHandler来处理全局异常。本节我们将借鉴框架提供的异常处理机制，完善全局异常的处理，并聊聊背后的故事。

02 全局异常处理重现

java 复制代码

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(BindException.class)
    public ResponseEntity<Map<String, Object>> handleValidationExceptions(BindException ex) {
        return ResponseEntity.badRequest().body(buildErrors(ex.getFieldError().getDefaultMessage()));
    }

    @ExceptionHandler(RuntimeException.class)
    public ResponseEntity<Map<String, Object>> handleException(RuntimeException ex) {
        return ResponseEntity.badRequest().body(buildErrors(ex.getMessage()));
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<Map<String, Object>> handleException(Exception ex) {
        return ResponseEntity.badRequest().body(buildErrors(ex.getMessage()));
    }

    private Map<String, Object> buildErrors(String msg) {
        Map<String, Object> body = new HashMap<>();
        body.put("success", false);
        body.put("msg", msg);
        body.put("data", null);
        return body;
    }
}

@ControllerAdvice是 Spring MVC 中一个非常强大且实用的注解，它的核心作用是提供全局的、跨多个控制器的增强处理。就像一个"全局拦截器"或"切面"。

@ExceptionHandler主要用来处理对应的异常，其中@ExceptionHandler(Exception.class)是兜底异常，匹配不到的异常最终都会走到里面。

在很多博主分享的文章中，都会说这里需要定义所有需要处理的异常。但是具体有哪些异常，始终没有参考的东西。

按照小编的设想，异常的处理如果只关心异常的信息提示，那只要分出e.getMessage()能不能取出异常信息，凡是不能取出的都需要特殊处理，如：

BindException：

e.getBindingResult().getFieldErrors()[0].getDefaultMessage
MissingServletRequestParameterException

e.getParameterName()获取缺失的字段。

其他的只需要兜底的异常即可。

03 框架自带全局异常

全局异常处理的异常也有被有些大牛单独列出来过，心想这么多异常谁能记住。我只关心能不能取到异常信息就好。

直到前两天整理SpringBoot配置的时候，看到了SpringBoot框架自带了一个异常处理器，几乎枚举了所有常见的异常.

ResponseEntityExceptionHandler：

java 复制代码

org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler

如果打算细分的朋友，可以参考这个类定制属于自己的异常处理器了。

04 异常解析器

configureHandlerExceptionResolvers

原本全局异常的处理，上面的内容已经足够了。但是分享SpringBoot的WebMvcConfigurer配置项的时候，才发现原来配置项也可以进行异常的统一处理。

这两个方法在配置项中已经介绍的很清楚了，这里不再赘述。

我们自定义异常处理器处理全局异常：

java 复制代码

public class AHandlerExceptionResolver implements HandlerExceptionResolver {

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        if (ex instanceof RuntimeException) {
            //...
        }else if (ex instanceof BindException) {
            //...
        }else {
            //...
        }
        return new ModelAndView();
    }
}

同样可以实现异常的统一处理

05 思考

@ExceptionHandler和configureHandlerExceptionResolvers到底有什么关系，执行的先后顺序又是怎样的？

从源码追踪来看，所有的异常处理来自这里：

而处理@ExceptionHandler注解的异常处理器是ExceptionHandlerExceptionResolver:

而ExceptionHandlerExceptionResolver的加载在初始化的时候，通过加@ControllerAdvice的Bean和加@ExceptionHandler的方法映射在一起。

而处理@ExceptionHandler注解的方法是ExceptionHandlerMethodResolver.

从继承关系来看，ExceptionHandlerExceptionResolver和自定义的AHandlerExceptionResolver都来自同一个接口HandlerExceptionResolver。所以说两个可以说是同一个东西。

至于先后顺序就简单了，所有的HandlerExceptionResolver都是顺序执行的，想要改变顺序可以通过list.add(index, xx)的方式。

但是自定义的异常处理器，可以控制异常是否继续向后执行，还是直接返回客户端。

06 小结

异常的处理，使用@ExceptionHandler + @ControllerAdvice已经基本满足日常的开发，简单且明了。如果想要更深层次的处理异常就需要自定义的异常处理器了。