前情概要

这个问题其实困扰了我一周时间，一周都在 Google 上旅游，我要如何动态的设置 @RestControllerAdvice 里面的 basePackages 以及 baseClasses 的值呢？经过一周的时间寻求无果之后打算决定放弃的我终于找到了一些关键的线索。
当然在此也感激这篇文章：@ControllerAdvice的用法和原理探究
其实我们只要有调试源码的习惯，也能够发现这些东西，可能有时候就是差那么一点动力吧，比如我，就想直接看现成的解析，没有那么主动去调试源码，哈哈哈。

发现了关键问题之后

其实从上面这篇文章里我提取到的关键信息如下：

@Bean
public HandlerExceptionResolver handlerExceptionResolver(
		@Qualifier("mvcContentNegotiationManager") ContentNegotiationManager contentNegotiationManager) {
	List<HandlerExceptionResolver> exceptionResolvers = new ArrayList<>();
	configureHandlerExceptionResolvers(exceptionResolvers);
	if (exceptionResolvers.isEmpty()) {
		addDefaultHandlerExceptionResolvers(exceptionResolvers, contentNegotiationManager);
	}
	extendHandlerExceptionResolvers(exceptionResolvers);
	HandlerExceptionResolverComposite composite = new HandlerExceptionResolverComposite();
	composite.setOrder(0);
	composite.setExceptionResolvers(exceptionResolvers);
	return composite;
}

PS：😓 后来我才发现这里面的 configureHandlerExceptionResolvers ，addDefaultHandlerExceptionResolvers 和extendHandlerExceptionResolvers 这三个方法是源码里面的，我还一直在找这个博主有关这两个方法的实现。

OK 回来，这里面的关键就是我需要往 Spring IOC 里面添加一个 HandlerExceptionResolverComposite ，并且设置它的处理器列表就好了。
于是我就顺着这个思路开始捣鼓，OK，下面是第一个版本的代码：

版本一

Starter 配置类(关键代码)

@Bean
public HandlerExceptionResolver handlerExceptionResolver() {
  final HandlerExceptionResolverComposite composite = new HandlerExceptionResolverComposite();
  final List<HandlerExceptionResolver> resolves =
      Collections.singletonList(new RestGlobalExceptionHandler(starterProperties));
  composite.setOrder(0);
  composite.setExceptionResolvers(resolves);
  return composite;
}

Handler 处理器类(关键代码)

public final class RestGlobalExceptionHandler extends DefaultHandlerExceptionResolver implements
    HandlerExceptionResolver {

  @Override
  public ModelAndView resolveException(
      final HttpServletRequest request,
      final HttpServletResponse response,
      final Object handler,
      final Exception ex) {
    ModelAndView view = new ModelAndView();
    if (ex instanceof BusinessException) {
      printToResponse(response, handlerError(request, (BusinessException) ex));
    } else if (ex instanceof MethodArgumentNotValidException) {
      printToResponse(response, handlerError(request, (MethodArgumentNotValidException) ex));
    } else {
      // use default exception handler
      view = super.doResolveException(request, response, handler, ex);
    }
    if (Objects.isNull(view)) {
      // use finally exception handler
      view = new ModelAndView();
      printToResponse(response, handlerError(request, ex));
    }
    return view;
  }
  // handlerError 以及 printToResponse 方法省略
}

这里说下为什么就要继承 DefaultHandlerExceptionResolver以及实现HandlerExceptionResolver接口：
实现接口：因为 HandlerExceptionResolverComposite类的 resolves 列表就是一个List<HandlerExceptionResolver>, 所以我们自定义的 Handler 需要实现这个接口。
继承 DefaultHandlerExceptionResolver类：因为可以看到我重写了 resolveException这个方法

但是这还存在问题：

// 这个是 DefaultHandlerExceptionResolver 的 doResolveException 方法，你们实践第一版的时候会发现，有一些异常信息被这方法处理了，但是我发现如果使用 @RestControllerAdvice 结合 @ExceptionHandler 的话，优先是考虑我们自定义的异常处理的，于是有了下面的版本二。
@Nullable
  protected ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {
    try {
      if (ex instanceof HttpRequestMethodNotSupportedException) {
        return this.handleHttpRequestMethodNotSupported((HttpRequestMethodNotSupportedException)ex, request, response, handler);
      }

      if (ex instanceof HttpMediaTypeNotSupportedException) {
        return this.handleHttpMediaTypeNotSupported((HttpMediaTypeNotSupportedException)ex, request, response, handler);
      }

      if (ex instanceof HttpMediaTypeNotAcceptableException) {
        return this.handleHttpMediaTypeNotAcceptable((HttpMediaTypeNotAcceptableException)ex, request, response, handler);
      }

      if (ex instanceof MissingPathVariableException) {
        return this.handleMissingPathVariable((MissingPathVariableException)ex, request, response, handler);
      }

      if (ex instanceof MissingServletRequestParameterException) {
        return this.handleMissingServletRequestParameter((MissingServletRequestParameterException)ex, request, response, handler);
      }

      if (ex instanceof ServletRequestBindingException) {
        return this.handleServletRequestBindingException((ServletRequestBindingException)ex, request, response, handler);
      }

      if (ex instanceof ConversionNotSupportedException) {
        return this.handleConversionNotSupported((ConversionNotSupportedException)ex, request, response, handler);
      }

      if (ex instanceof TypeMismatchException) {
        return this.handleTypeMismatch((TypeMismatchException)ex, request, response, handler);
      }

      if (ex instanceof HttpMessageNotReadableException) {
        return this.handleHttpMessageNotReadable((HttpMessageNotReadableException)ex, request, response, handler);
      }

      if (ex instanceof HttpMessageNotWritableException) {
        return this.handleHttpMessageNotWritable((HttpMessageNotWritableException)ex, request, response, handler);
      }

      if (ex instanceof MethodArgumentNotValidException) {
        return this.handleMethodArgumentNotValidException((MethodArgumentNotValidException)ex, request, response, handler);
      }

      if (ex instanceof MissingServletRequestPartException) {
        return this.handleMissingServletRequestPartException((MissingServletRequestPartException)ex, request, response, handler);
      }

      if (ex instanceof BindException) {
        return this.handleBindException((BindException)ex, request, response, handler);
      }

      if (ex instanceof NoHandlerFoundException) {
        return this.handleNoHandlerFoundException((NoHandlerFoundException)ex, request, response, handler);
      }

      if (ex instanceof AsyncRequestTimeoutException) {
        return this.handleAsyncRequestTimeoutException((AsyncRequestTimeoutException)ex, request, response, handler);
      }
    } catch (Exception var6) {
      Exception handlerEx = var6;
      if (this.logger.isWarnEnabled()) {
        this.logger.warn("Failure while trying to resolve exception [" + ex.getClass().getName() + "]", handlerEx);
      }
    }

    return null;
  }

版本二

这里主要解决的是，有一些自定义的异常处理提前被 DefaultHandlerExceptionResolver 类的 doResolveException 的方法处理了，了解 Spring IOC 容器的小伙伴应该都知道，这很容易让我们联想起，Bean 的顺序问题，那么我们哪里设置了我们自定义 Bean 的顺序呢，也就是使用 @Order 或者代码里面设置了，没错，就是这里：

@Bean
public HandlerExceptionResolver handlerExceptionResolver() {
  final HandlerExceptionResolverComposite composite = new HandlerExceptionResolverComposite();
  final List<HandlerExceptionResolver> resolves =
      Collections.singletonList(new RestGlobalExceptionHandler(starterProperties));
  // 这里，这里，这里
  composite.setOrder(0);
  composite.setExceptionResolvers(resolves);
  return composite;
}

但是我们要怎么知道我们具体要设置的值是什么呢？大家都知道在使用 Spring 的时候设置 Bean 的 Order 值越小那么它的优先级越高，所以我尝试着把 0 换成 -1，试试，结果还真成功了，我们自定义的优先执行了，但是作为一个搞技术的人，还是想摸清楚它的原理吧，为啥设置成 -1 就可以了呢？
一开始没有啥头绪，不知道怎么去查找 Spring 配置异常处理这块( 主要还是源码不熟 -_-! )，但后面想一想，把目标换一下不就好了，是因为 DefaultHandlerExceptionResolver 这个 Bean 的原因，那我就找 Spring 是哪里把他放进 Spring IOC 容器的不就好了。因为我使用的框架是 SpringBoot，所以相关的配置肯定在 XXXAutoConfiguration 类里面，于是就找找找…

• WebMvcAutoConfiguration 没有…
• DispatcherServletAutoConfiguration 没有…

好吧最后还是借助 IntelliJ 这个工具，因为我们自定义的是一个 HandlerExceptionResolverComposite Bean，所以我们进入这个类：

发现它实现了 HandlerExceptionResolver 这个接口，一般 Spring 都会使用接口作为一个接收实现的变量，然后 return 回去交给 Spring IOC 容器，所以我们再进入这个接口：

利用 IntelliJ 的工具，找到哪里注入了这个 Bean：


进去之后发现了跟我们类似的代码：

看到 618 行的 this.addDefaultHandlerExceptionResolvers(exceptionResolvers, contentNegotiationManager); 吗？这个就是添加 DefaultHandlerExceptionResolver 的地方，并且设置的 Order 是 0，如果 Debug 的话你会发现这个方法除了加入 DefaultHandlerExceptionResolver 之外，还会加入自定义使用注解的异常处理器，但是它在 List 中的顺序比 DefaultHandlerExceptionResolver 靠前，所以它会优先使用自定义的处理器处理，但是使用注解是 Spring 自己处理的，然后加入这个 List 中，我们没办法去修改这个 List，但是我们知道了可以自定义 HandlerExceptionResolverComposite 并且把它的 Order 设置成比 0 小就好了，所以这就是为什么我们设置成 -1 就可以覆盖 DefaultHandlerExceptionResolver 的行为的原因。

所有的代码已经放在我的代码仓库：码云，欢迎来访以及给我小⭐⭐