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 -
MissingServletRequestParameterExceptione.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已经基本满足日常的开发，简单且明了。如果想要更深层次的处理异常就需要自定义的异常处理器了。