深入理解 Spring 异常处理

1.前言

相信我们每个人在 SpringMVC 开发中,都遇到这样的问题:当我们的代码正常运行时,返回的数据是我们预期格式,比如 json 或 xml 形式,但是一旦出现了异常(比如:NPE 或者数组越界等等),返回的内容却是服务端的异常堆栈信息,从而导致返回的数据不能使客户端正常解析; 很显然,这些并不是我们希望的结果。

我们知道,一个较为常见的系统,会涉及控制层,服务 (业务) 层、缓存层、存储层以及接口调用等,其中每一个环节都不可避免的会遇到各种不可预知的异常需要处理。如果每个步骤都单独 try…catch 会使系统显的很杂乱,可读性差,维护成本高;常见的方式就是,实现统一的异常处理,从而将各类异常从各个模块中解耦出来;

2.常见全局异常处理

在 Spring 中常见的全局异常处理,主要有三种:

(1)注解 ExceptionHandler

(2)继承 HandlerExceptionResolver 接口

(3)注解 ControllerAdvice

在后面的讲解中,主要以 HTTP 错误码:400(请求无效)和 500(内部服务器错误)为例,先看一下测试代码以及没有任何处理的返回结果,如下:
https://static001.infoq.cn/resource/image/50/80/50d95e1b3b71501e59147f3a8ec08780.png
https://static001.infoq.cn/resource/image/59/90/59de234c16fca48ebada4e8629465490.png
图 1:测试代码

2.1 注解 ExceptionHandler

注解 ExceptionHandler 作用对象为方法,最简单的使用方法就是放在 controller 文件中,详细的注解定义不再介绍。如果项目中有多个 controller 文件,通常可以在 baseController 中实现 ExceptionHandler 的异常处理,而各个 contoller 继承 basecontroller 从而达到统一异常处理的目的。因为比较常见,简单代码如下:
https://static001.infoq.cn/resource/image/66/91/669ad5a175ec3f567c3b2fc52381b991.png
在返回异常时,添加了所属的类名,便于大家记忆理解。运行看一下结果:
https://static001.infoq.cn/resource/image/d0/eb/d030924710e803df9dce2d68f423cdeb.png
图 4:添加 ExceptionHandler 之后的结果
优点:ExceptionHandler 简单易懂,并且对于异常处理没有限定方法格式;
缺点:由于 ExceptionHandler 仅作用于方法,对于多个 controller 的情况,仅为了一个方法,所有需要异常处理的 controller 都继承这个类,明明不相关的东西,强行给他们找个爹,不太好

2.2 注解 ControllerAdvice

这里虽说是 ControllerAdvice 注解,其实是其与 ExceptionHandler 的组合使用。在上文中可以看到,单独使用 @ExceptionHandler 时,其必须在一个 Controller 中,然而当其与 ControllerAdvice 组合使用时就完全没有了这个限制。换句话说,二者的组合达到的全局的异常捕获处理。
https://static001.infoq.cn/resource/image/ba/e2/ba58142d48a0b93076196cf5ea8483e2.png
https://static001.infoq.cn/resource/image/ba/e2/ba58142d48a0b93076196cf5ea8483e2.png
图 5:注解 ControllerAdvice 异常处理代码
在运行之前,需将之前 Controller 中的 ExceptionHandler 注释掉,测试结果如下:
https://static001.infoq.cn/resource/image/32/c2/321bd547451362b856e9893eb90f72c2.png
图 6:注解 ControllerAdvice 异常处理结果

通过上面结果可以看到,异常处理确实已经变更为 ExceptionHandlerAdvice 类。这种方法将所有的异常处理整合到一处,去除了 Controller 中的继承关系,并且达到了全局捕获的效果,推荐使用此类方式;

2.3 实现 HandlerExceptionResolver 接口

HandlerExceptionResolver 本身 SpringMVC 内部的接口,其内部只有 resolveException 一个方法,通过实现该接口我们可以达到全局异常处理的目的。
https://static001.infoq.cn/resource/image/a2/09/a2f327167a6147e8b88bd6a9631b9f09.png
图 7:实现 HandlerExceptionResolver 接口
同样在执行之前,将上述两个方法的异常处理都注释掉,运行结果如下:
https://static001.infoq.cn/resource/image/32/3a/32db2dd9485f7d7d97afe2e27a76263a.png
图 8:实现 HandlerExceptionResolver 接口运行结果

可以看到 500 的异常处理已经生效了,但是 400 的异常处理却没有生效,并且根没有异常前的返回结果一样。这是怎么回事呢?不是说可以做到全局异常处理的么?没办法要想知道问题的原因,我们只能刨根问底,往 Spring 的祖坟上刨,下面我们结合 Spring 的源码调试,去需要原因。

3.Spring 中异常处理源码分析

大家都知道,在 Spring 中第一个收到请求的类就是 DispatcherServlet,而该类中核心的方法就是 doDispatch,我们可以在该类中打断点,进而一步步跟进异常处理。

3.1 HandlerExceptionResolver 实现类处理流程

参照如下的跟进步骤,在 processHandlerException 中断点,跟踪的结果如下图:

https://static001.infoq.cn/resource/image/ca/35/ca925401e7b970022fc0f13b80aca635.png
https://static001.infoq.cn/resource/image/5f/b9/5f3f83aeb1bbcc08b34a0d90b94023b9.png
图 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 这两个的顺序谁先谁后呢? 将三类异常处理全部打开(之前注释掉了),运行一下看看效果:
https://static001.infoq.cn/resource/image/ec/61/ec013bbd39c410beb39db85e845e8061.png
图 10:异常处理全放开运行结果

通过现象可以看到,Controller 中单独 @ExceptionHandle 异常处理排在了首位,@ControllerAdvice 排在了第二位。严谨的童鞋可以写个 Controller02,将 query 和 calc 复制过去,异常处理就不要了,这样请求 c02 的方法时,异常捕获的所属类名就都是 @ControllerAdvice 所在类了。

以上都是我们根据现象得到的结论,下面去 Spring 源码去找“证据”。在图 9 中,handlerExceptionResolvers 中有 4 类处理器,而 @ExceptionHandler 和 @ControllerAdvice 的处理就在第一个 ExceptionHandlerExceptionResolver 中(之前断点跟进即可获知)。继续跟进直到进入 ExceptionHandlerExceptionResolver 类的 doResolveHandlerMethodException 方法,这里的 HandlerMethod 就是 Spring 将 HTTP 请求映射到指定 Controller 中的方法,而 Exception 就是需要被捕获的异常;继续跟进,看看使用这两个参数到底干了什么事儿。

https://static001.infoq.cn/resource/image/d2/94/d2d06f441e90eba098d6eca950247d94.png
图 11:doResolveHandlerMethodException 断点

继续跟进 getExceptionHandlerMethod 方法,发现有两个变量可能就是问题的关键:exceptionHandlerCache 和 exceptionHandlerAdviceCache。首先,两者的变量名很值得怀疑;其次,前者在代码中看,明显是通过类作为 key,从而得到一个处理器 (resolver),这恰好 Controller 中 @ExceptionHandler 处理规则相吻合;最后,这两个 Cache 的处理顺序,也符合之前的得到的结论。正如之前猜测的那样,Spring 中确实是优先根据 Controller 类名去查找对应的 ExceptionHandler,没有找到的话,再进行 @ControllerAdvice 异常处理。

https://static001.infoq.cn/resource/image/2b/0f/2ba42f11acd7a146e03250db7e338e0f.png
图 12:两个异常处理 Cache

如有兴趣可继续深入挖掘 Spring 的源码,这里针对 ExceptionHandlerExceptionResolver 简单做个总结:

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

介绍了这么多,简单画张图总结一下。蓝色的部分是 Spring 默认添加的 3 类异常处理器,黄色部分是我们添加的异常处理以及其所被调用的位置和顺序。看看哪里还有不太清楚的,往回翻翻看(ResponseStatusExceptionResolver 是针对 @ResponseStatus 注解,这里不再详述)。
https://static001.infoq.cn/resource/image/47/63/47f1185d4be8be57ca18ec860a2ff863.png
图 13:异常总结

如果有需要将 MyHandlerExceptionResolver 提前处理,甚至排在 ExceptionHandlerExceptionResolver 之前,能做到么?答案是肯定的,在 Spring 中如果想将 MyHandlerExceptionResolver 异常处理提前,需要再实现一个 Ordered 接口,实现里面的 getOrder 方法即可,这里返回 -1,将其放在最上面,这次咸鱼终于可以翻身了。

https://static001.infoq.cn/resource/image/0b/0e/0b1e16d976bfb3c3d88856fcb02b1d0e.png
图 14:实现 Ordered 接口

运行看一下结果是不是符合预期,提醒一下,我们三个异常处理都是生效的,如下图:
https://static001.infoq.cn/resource/image/f3/8a/f30a595b2eedd03891fc96b934d1c98a.png
图 15:实现 Ordered 接口运行结果

4. 总结

本文主要通过介绍 SpringMVC 中三类常见的全局异常处理,在调试中发现了问题,进而引发去 Spring 源码中去探究原因,最终解决问题,希望大家能有所收获。当然 Spring 异常处理类不止介绍的这些,有兴趣的童鞋请自行探索!

参考链接:
[1] http://www.cnblogs.com/fangjian0423/p/springMVC-request-mapping.html
[2] https://blog.csdn.net/mll999888/article/details/77621352

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值