@ExceptionHandler or HandlerExceptionResolver？如何优雅处理全局异常？【享学Spring MVC】（上）-阿里云开发者社区

前言

阅读上文，了解到了可以通过自定义HandlerExceptionResolver实现来处理程序异常，当然Spring MVC也内置了一些实现来对异常处理进行支持。但是作为新时代的程序员，我估计已经很少人知道HandlerExceptionResolver这个异常处理器接口（更有甚者连ModelAndView都没听说过也大有人在啊），虽然这不应该，但存在即合理。因此从现象上可以认为使用自定义HandlerExceptionResolver实现的方式去处理异常已经out了，它已经被新的方式所取代：@ExceptionHandler方式，这就是本章节的核心议题，来探讨它的使用以及原理。

回忆上篇文章讲述HandlerExceptionResolver，你是否疑问过这个问题：通过HandlerExceptionResolver如何返回一个json串呢？其实这个问题雷同于：源生Servlet如何给前端返回一个json串呢？因为上文的示例都是返回的一个ModelAndView页面，so本文在最开头先解决这个疑问，为下面内容做个铺垫吧。

HandlerExceptionResolver如何返回JSON格式数据？

基于上篇文章案例自定义了一个异常处理器来处理Handler抛出的异常，示例中返回的是一个页面ModelAndView。但是通常情况下我们的应用都是REST应用，我们的接口返回的都是一个JSON串，那么若接口抛出异常的话我们处理好后也同样的返回一个JSON串比返回一个页面更为合适。

这时若你项目较老，使用的仍旧是HandlerExceptionResolver方式处理异常的话，我在本处提供两种处理方式，供以参考：

方式一：response直接输出json

自定义异常处理器（匿名实现）：

@Configuration
@EnableWebMvc
public class WebMvcConfig extends WebMvcConfigurerAdapter {
    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> exceptionResolvers) {
        // 自定义异常处理器一般请放在首位
        exceptionResolvers.add(0, new AbstractHandlerExceptionResolver() {
            @Override
            protected ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
                response.setContentType("application/json;charset=UTF-8");
                response.setCharacterEncoding("UTF-8");
                try {
                    String jsonStr = "";
                    if (ex instanceof BusinessException) {
                        response.setStatus(HttpStatus.OK.value());
                        jsonStr = "{'code':100001,'message':'业务异常，请联系客服处理'}";
                    } else {
                        response.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
                        jsonStr = "{'code':500,'message':'服务器未知异常'}";
                    }
                    response.getWriter().print(jsonStr);
                    response.getWriter().flush();
                    response.getWriter().close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
                return null;
            }
        });
    }
}

访问截图如下：

注意事项：

因为return null，所以后面若还有处理器将继续执行。但因为本处已把response close了，因此请确保后面不会再使用此response
若所有Resolver处理完后还是return null，那Spring MVC将直接throw ex，因此你看到的效果是：控制台上有异常栈，但是前段页面上显示是友好的json串。
因为木有ModelAndView（值为null），所以不会有渲染步骤，因此后续步骤Spring MVC也不会再使用到response（自定义的拦截器除外~）。

方式二：借助MappingJackson2JsonView

自定义异常处理器，借助MappingJackson2JsonView这个json视图实现：

@Configuration
@EnableWebMvc
public class WebMvcConfig extends WebMvcConfigurerAdapter {
    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> exceptionResolvers) {
        // 自定义异常处理器一般请放在首位
        exceptionResolvers.add(0, new AbstractHandlerExceptionResolver() {
            @Override
            protected ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
                ModelAndView mv = new ModelAndView();
                MappingJackson2JsonView view = new MappingJackson2JsonView();
                view.setJsonPrefix("fsxJson"); // 设置JSON前缀，有的时候很好用的哦
                //view.setModelKey(); // 让只序列化指定的key
                mv.setView(view);
                // 这样添加key value就非常方便
                mv.addObject("code", "100001");
                mv.addObject("message", "业务异常，请联系客服处理");
                return mv;
            }
        });
    }
}

访问截图如下：

显然这种使用JsonView的方式代码看起来更加舒服，使用起来更加的面向对象。

这两种方式都是基于自定义HandlerExceptionResolver实现类的方式来处理异常，最终给前端返回一个json串。虽然方式二看起来步骤也不麻烦，也够面向对象，但接下来的@ExceptionHandler方式可谓是杀手级的应用~

@ExceptionHandler

此注解是Spring 3.0后提供的处理异常的注解，整个Spring在3.0+中新增了大量的能力来对REST应用提供支持，此注解便是其中之一。

它(只能)标注在方法上，可以使得这个方法成为一个异常处理器，处理指定的异常类型。

// @since 3.0
@Target(ElementType.METHOD) // 只能标注在方法上
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ExceptionHandler {
  // 指定异常类型，可以多个
  Class<? extends Throwable>[] value() default {};
}

上篇讲解HandlerExceptionResolver的原理部分讲到了，DispatcherServlet对异常的处理最终都是无一例外的交给了HandlerExceptionResolver异常处理器，因此很容易想到@ExceptionHandler它的底层实现原理其实也是一个异常处理器，它便是：ExceptionHandlerExceptionResolver。

在分析它之前，需要先前置介绍两个类：AbstractHandlerMethodExceptionResolver和ExceptionHandlerMethodResolver

AbstractHandlerMethodExceptionResolver

它是ExceptionHandlerExceptionResolver的抽象父类，服务于处理器类型是HandlerMethod类型的抛出的异常，它并不规定实现方式必须是@ExceptionHandler。它复写了抽象父类AbstractHandlerExceptionResolver的shouldApplyTo方法：

// @since 3.1 专门处理HandlerMethod类型是HandlerMethod类型的异常
public abstract class AbstractHandlerMethodExceptionResolver extends AbstractHandlerExceptionResolver {
  // 只处理HandlerMethod这种类型的处理器抛出的异常~~~~~~
  @Override
  protected boolean shouldApplyTo(HttpServletRequest request, @Nullable Object handler) {
    if (handler == null) {
      return super.shouldApplyTo(request, null);
    } else if (handler instanceof HandlerMethod) {
      HandlerMethod handlerMethod = (HandlerMethod) handler;
      // 可以看到最终getBean表示最终哪去验证的是它所在的Bean类，而不是方法本身
      // 所以异常的控制是针对于Controller这个类的~
      handler = handlerMethod.getBean(); 
      return super.shouldApplyTo(request, handler);
    } else {
      return false;
    }
  }
  @Override
  @Nullable
  protected final ModelAndView doResolveException(HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {
    return doResolveHandlerMethodException(request, response, (HandlerMethod) handler, ex);
  }
  @Nullable
  protected abstract ModelAndView doResolveHandlerMethodException(HttpServletRequest request, HttpServletResponse response, @Nullable HandlerMethod handlerMethod, Exception ex);
}

此抽象类非常简单：规定了只处理HandlerMethod抛出的异常。

ExceptionHandlerMethodResolver（重要）

它是一个会在Class及Class的父类中找出带有@ExceptionHandler注解的类，该类带有key为Throwable，value为Method的缓存属性，提供匹配效率。

// @since 3.1
public class ExceptionHandlerMethodResolver {
  // A filter for selecting {@code @ExceptionHandler} methods.
  public static final MethodFilter EXCEPTION_HANDLER_METHODS = method -> AnnotatedElementUtils.hasAnnotation(method, ExceptionHandler.class);
  // 两个缓存：key：异常类型   value：目标方法Method
  private final Map<Class<? extends Throwable>, Method> mappedMethods = new HashMap<>(16);
  private final Map<Class<? extends Throwable>, Method> exceptionLookupCache = new ConcurrentReferenceHashMap<>(16);
  // 唯一构造函数
  // detectExceptionMappings：传入method，找到这个Method可以处理的所有的异常类型们（注意此方法的逻辑）
  // addExceptionMapping：把异常类型和Method缓存进mappedMethods里
  public ExceptionHandlerMethodResolver(Class<?> handlerType) {
    for (Method method : MethodIntrospector.selectMethods(handlerType, EXCEPTION_HANDLER_METHODS)) {
      for (Class<? extends Throwable> exceptionType : detectExceptionMappings(method)) {
        addExceptionMapping(exceptionType, method);
      }
    }
  }
  // 找到此Method能够处理的所有的异常类型
  // 1、detectAnnotationExceptionMappings：本方法或者父类的方法上标注有ExceptionHandler注解，然后读取出其value值就是它能处理的异常们
  // 2、若value值木有指定，那所有的方法入参们的异常类型，就是此方法能够处理的所有异常们
  // 3、若最终还是空，那就抛出异常：No exception types mapped to " + method
  private List<Class<? extends Throwable>> detectExceptionMappings(Method method) {
    List<Class<? extends Throwable>> result = new ArrayList<>();
    detectAnnotationExceptionMappings(method, result);
    if (result.isEmpty()) {
      for (Class<?> paramType : method.getParameterTypes()) {
        if (Throwable.class.isAssignableFrom(paramType)) {
          result.add((Class<? extends Throwable>) paramType);
        }
      }
    }
    if (result.isEmpty()) {
      throw new IllegalStateException("No exception types mapped to " + method);
    }
    return result;
  }
  // 对于添加方法一样有一句值得说的：
  // 若不同的Method表示可以处理同一个异常，那是不行的："Ambiguous @ExceptionHandler method mapped for [" 
  // 注意：此处必须是同一个异常（比如Exception和RuntimeException不属于同一个...）
  private void addExceptionMapping(Class<? extends Throwable> exceptionType, Method method) {
    Method oldMethod = this.mappedMethods.put(exceptionType, method);
    if (oldMethod != null && !oldMethod.equals(method)) {
      throw new IllegalStateException("Ambiguous @ExceptionHandler method mapped for [" + exceptionType + "]: {" + oldMethod + ", " + method + "}");
    }
  }
  // 给指定的异常exception匹配上一个Method方法来处理
  // 若有多个匹配上的：使用ExceptionDepthComparator它来排序。若木有匹配的就返回null
  @Nullable
  public Method resolveMethod(Exception exception) {
    return resolveMethodByThrowable(exception);
  }
  // @since 5.0 递归到了couse异常类型 也会处理
  @Nullable
  public Method resolveMethodByThrowable(Throwable exception) {
    Method method = resolveMethodByExceptionType(exception.getClass());
    if (method == null) {
      Throwable cause = exception.getCause();
      if (cause != null) {
        method = resolveMethodByExceptionType(cause.getClass());
      }
    }
    return method;
  }
  //1、先去exceptionLookupCache找，若匹配上了直接返回
  // 2、再去mappedMethods这个缓存里找。很显然可能匹配上多个，那就用ExceptionDepthComparator排序匹配到一个最为合适的
  // 3、匹配上后放进缓存`exceptionLookupCache`，所以下次进来就不需要再次匹配了，这就是缓存的效果
  // ExceptionDepthComparator的基本理论上：精确匹配优先（按照深度比较）
  @Nullable
  public Method resolveMethodByExceptionType(Class<? extends Throwable> exceptionType) {
    Method method = this.exceptionLookupCache.get(exceptionType);
    if (method == null) {
      method = getMappedMethod(exceptionType);
      this.exceptionLookupCache.put(exceptionType, method);
    }
    return method;
  }
}

对于本类的功能，可总结如下：

1.找到指定Class类（可能是Controller本身，也可能是@ControllerAdvice）里面所有标注有@ExceptionHandler的方法们

2.同一个Class内，不能出现同一个（注意理解同一个的含义）异常类型被多个Method处理的情况，否则抛出异常：Ambiguous @ExceptionHandler method mapped for ...

1. 相同异常类型处在不同的Class内的方法上是可以的，比如常见的一个在Controller内，一个在@ControllerAdvice内~

3.提供缓存：

1. mappedMethods：每种异常对应的处理方法（直接映射代码上书写的异常-方法映射）

2. exceptionLookupCache：经过按照深度逻辑精确匹配上的Method方法

4.既能处理本身的异常，也能够处理getCause()导致的异常

5.ExceptionDepthComparator的匹配逻辑是按照深度匹配。比如发生的是NullPointerException，但是声明的异常有Throwable和Exception，这是它会根据异常的最近继承关系找到继承深度最浅的那个异常，即Exception。

@ExceptionHandler or HandlerExceptionResolver？如何优雅处理全局异常？【享学Spring MVC】（上）

前言

HandlerExceptionResolver如何返回JSON格式数据？

方式二：借助MappingJackson2JsonView

@ExceptionHandler

AbstractHandlerMethodExceptionResolver

ExceptionHandlerMethodResolver（重要）

热门文章

最新文章

相关课程

相关电子书

相关实验场景