深入理解Spring异常处理

jiezi

6 年前

1. 前言
相信我们每个人在 Spring MVC 开发中，都遇到这样的问题：当我们的代码正常运行时，返回的数据是我们预期格式，比如 json 或 xml 形式，但是一旦出现了异常（比如：NPE 或者数组越界等等），返回的内容确实服务端的异常堆栈信息，从而导致返回的数据不能使客户端正常解析；很显然，这些并不是我们希望的结果。
我们知道，一个较为常见的系统，会涉及控制层，服务 (业务) 层、缓存层、存储层以及接口调用等，其中每一个环节都不可避免的会遇到各种不可预知的异常需要处理。如果每个步骤都单独 try..catch 会使系统显的很杂乱，可读性差，维护成本高；常见的方式就是，实现统一的异常处理，从而将各类异常从各个模块中解耦出来；
2. 常见全局异常处理
在 Spring 中常见的全局异常处理，主要有三种：
（1）注解 ExceptionHandler
（2）继承 HandlerExceptionResolver 接口
（3）注解 ControllerAdvice
在后面的讲解中，主要以 HTTP 错误码：400（请求无效）和 500（内部服务器错误）为例，先看一下测试代码以及没有任何处理的返回结果，如下：

图 1：测试代码
图 2：没有异常的错误返回
2.1 注解 ExceptionHandler
注解 ExceptionHandler 作用对象为方法，最简单的使用方法就是放在 controller 文件中，详细的注解定义不再介绍。如果项目中有多个 controller 文件，通常可以在 baseController 中实现 ExceptionHandler 的异常处理，而各个 contoller 继承 basecontroller 从而达到统一异常处理的目的。因为比较常见，简单代码如下：
图 3：Controller 中的 ExceptionHandler 使用
在返回异常时，添加了所属的类名，便于大家记忆理解。运行看一下结果：
图 4：添加 ExceptionHandler 之后的结果

优点：ExceptionHandler 简单易懂，并且对于异常处理没有限定方法格式；
缺点：由于 ExceptionHandler 仅作用于方法，对于多个 controller 的情况，仅为了一个方法，所有需要异常处理的 controller 都继承这个类，明明不相关的东西，强行给他们找个爹，不太好。

2.2 注解 ControllerAdvice
这里虽说是 ControllerAdvice 注解，其实是其与 ExceptionHandler 的组合使用。在上文中可以看到，单独使用 @ExceptionHandler 时，其必须在一个 Controller 中，然而当其与 ControllerAdvice 组合使用时就完全没有了这个限制。换句话说，二者的组合达到的全局的异常捕获处理。图 5：注解 ControllerAdvice 异常处理代码
在运行之前，需将之前 Controller 中的 ExceptionHandler 注释掉，测试结果如下：图 6：注解 ControllerAdvice 异常处理结果
通过上面结果可以看到，异常处理确实已经变更为 ExceptionHandlerAdvice 类。这种方法将所有的异常处理整合到一处，去除了 Controller 中的继承关系，并且达到了全局捕获的效果，推荐使用此类方式；
2.3 实现 HandlerExceptionResolver 接口
HandlerExceptionResolver 本身 SpringMVC 内部的接口，其内部只有 resolveException 一个方法，通过实现该接口我们可以达到全局异常处理的目的。图 7：实现 HandlerExceptionResolver 接口同样在执行之前，将上述两个方法的异常处理都注释掉，运行结果如下：图 8：实现 HandlerExceptionResolver 接口运行结果
可以看到 500 的异常处理已经生效了，但是 400 的异常处理却没有生效，并且根没有异常前的返回结果一样。这是怎么回事呢？不是说可以做到全局异常处理的么？没办法要想知道问题的原因，我们只能刨根问底，往 Spring 的祖坟上刨，下面我们结合 Spring 的源码调试，去需要原因。
3.Spring 中异常处理源码分析
大家都知道，在 Spring 中第一个收到请求的类就是 DispatcherServlet，而该类中核心的方法就是 doDispatch，我们可以在该类中打断点，进而一步步跟进异常处理。
3.1 HandlerExceptionResolver 实现类处理流程
参照如下的跟进步骤，在 processHandlerException 中断点，跟踪的结果如下图：图 9：processHandlerException 断点
可以看到在图中箭头【1】处，在遍历 handlerExceptionResolvers 进而来处理异常，而在箭头【2】处，看到 handlerExceptionResolvers 中共有 4 个元素，其中最后一个就是 2.3 方法定义的异常处理类。
当前的请求 query 请求，根据上述现象可以推测出，该异常处理应该是在前 3 个异常处理中被处理了，从而跳过我们自定义的异常；带着这样的猜测，我们 F8 继续跟进，可以跟踪到该异常是被第三个，即 DefaultHandlerExceptionResolver 所处理。
DefaultHandlerExceptionResolver SpringMVC 默认装配了 DefaultHandlerExceptionResolver，该类的 doResolveException 方法中主要对一些特殊的异常进行处理，并将这类异常转换为相应的响应状态码。而 query 请求触发的异常为 MissingServletRequestParameterException，其恰好也是被 DefaultHandlerExceptionResolver 所针对的异常，故会在该类中被异常捕获。
到此真相大白了，可以看到我们的自定义类 MyHandlerExceptionResolver 确实可以做到全局处理异常，只不过对于 query 请求的异常，中间被 DefaultHandlerExceptionResolver 插了一脚，所以就跳过了 MyHandlerExceptionResolver 类的处理，从而出现 400 的返回结果。而对于 calc 请求，中间没有阻拦，所以就达到了预期效果。
3.2 三类异常的处理顺序
到此我们一共介绍了 3 类全局异常处理，按照上面的分析可以看出，实现 HandlerExceptionResolver 接口的方式是排在最后处理，那么 @ExceptionHandler 和 @ControllerAdvice 这两个的顺序谁先谁后呢？将三类异常处理全部打开（之前注释掉了），运行一下看看效果：图 10：异常处理全放开运行结果
通过现象可以看到，Controller 中单独 @ExceptionHandle 异常处理排在了首位，@ControllerAdvice 排在了第二位。严谨的童鞋可以写个 Controller02，将 query 和 calc 复制过去，异常处理就不要了，这样请求 c02 的方法时，异常捕获的所属类名就都是 @ControllerAdvice 所在类了。
以上都是我们根据现象得到的结论，下面去 Spring 源码去找“证据”。在图 9 中，handlerExceptionResolvers 中有 4 类处理器，而 @ExceptionHandler 和 @ControllerAdvice 的处理就在第一个 ExceptionHandlerExceptionResolver 中（之前断点跟进即可获知）。继续跟进直到进入 ExceptionHandlerExceptionResolver 类的 doResolveHandlerMethodException 方法，这里的 HandlerMethod 就是 Spring 将 HTTP 请求映射到指定 Controller 中的方法，而 Exception 就是需要被捕获的异常；继续跟进，看看使用这两个参数到底干了什么事儿。
图 11：doResolveHandlerMethodException 断点
继续跟进 getExceptionHandlerMethod 方法，发现有两个变量可能就是问题的关键：exceptionHandlerCache 和 exceptionHandlerAdviceCache。首先，两者的变量名很值得怀疑；其次，前者在代码中看，明显是通过类作为 key，从而得到一个处理器(resolver)，这恰好 Controller 中 @ExceptionHandler 处理规则相吻合；最后，这两个 Cache 的处理顺序，也符合之前的得到的结论。正如之前猜测的那样，Spring 中确实是优先根据 Controller 类名去查找对应的 ExceptionHandler，没有找到的话，再进行 @ControllerAdvice 异常处理。图 12：两个异常处理 Cache
** 如有兴趣可继续深入挖掘 Spring 的源码，这里针对 ExceptionHandlerExceptionResolver 简单做个总结：**

exceptionHandlerCache 中包含 Controller 中的 ExceptionHandler 异常处理，处理时通过 HandlerMethod 得到 Controller，进而再找到异常处理方法，需要注意的是，其是在异常处理过程中 put 值的；
exceptionHandlerAdviceCache 则是在项目启动时初始化的，大概思路是找到带有 @ControllerAdvice 注解的 bean，从而缓存 bean 中的 ExceptionHandler，在异常处理时需要对齐遍历查找处理，进而达到全局处理的目的。

3.3 咸鱼翻身
介绍了这么多，简单画张图总结一下。蓝色的部分是 Spring 默认添加的 3 类异常处理器，黄色部分是我们添加的异常处理以及其所被调用的位置和顺序。看看哪里还有不太清楚的，往回翻翻看（ResponseStatusExceptionResolver 是针对 @ResponseStatus 注解，这里不再详述）。图 13：异常总结
如果有需要将 MyHandlerExceptionResolver 提前处理，甚至排在 ExceptionHandlerExceptionResolver 之前，能做到么？答案是肯定的，在 Spring 中如果想将 MyHandlerExceptionResolver 异常处理提前，需要再实现一个 Ordered 接口，实现里面的 getOrder 方法即可，这里返回 -1，将其放在最上面，这次咸鱼终于可以翻身了。图 14：实现 Ordered 接口
运行看一下结果是不是符合预期，提醒一下，我们三个异常处理都是生效的，如下图：图 15：实现 Ordered 接口运行结果
4. 总结
本文主要通过介绍 SpringMVC 中三类常见的全局异常处理，在调试中发现了问题，进而引发去 Spring 源码中去探究原因，最终解决问题，希望大家能有所收获。当然 Spring 异常处理类不止介绍的这些，有兴趣的童鞋请自行探索！
参考链接：
[1] http://www.cnblogs.com/fangji…
[2] https://blog.csdn.net/mll9998…
作者：张远航宜信技术学院链接描述