满屏的try-catch，不瘆得慌？
作 者：码猿技术专栏
原文链接：
文章插图
目录
- 前言
- Spring Boot 版本
- 全局统一异常处理的前世今生
- Spring Boot的异常如何分类？
- 如何统一异常处理？
- 异常匹配的顺序是什么？
- 总结
冗余的代码往往会丧失写代码的动力 ， 每天搬砖似的写代码 ， 真的很难受 。 今天这篇文章教你如何去掉满屏的try(){...}catch(){...}finally{...} ， 解放你的双手 。
Spring Boot 版本本文基于的Spring Boot的版本是2.3.4.RELEASE 。
全局统一异常处理的前世今生早在Spring 3.x就已经提出了@ControllerAdvice ， 可以与@ExceptionHandler、@InitBinder、@ModelAttribute 等注解注解配套使用 ， 这几个此处就不再详细解释了 。
这几个注解小眼一瞟只有@ExceptionHandler与异常有关啊 ， 翻译过来就是异常处理器 。 其实异常的处理可以分为两类 ， 分别是局部异常处理和全局异常处理 。
局部异常处理：@ExceptionHandler和@Controller注解搭配使用 ， 只有指定的controller层出现了异常才会被@ExceptionHandler捕获到 ， 实际生产中怕是有成百上千个controller了吧 ， 显然这种方式不合适 。
全局异常处理：既然局部异常处理不合适了 ， 自然有人站出来解决问题了 ， 于是就有了@ControllerAdvice这个注解的横空出世了 ， @ControllerAdvice搭配@ExceptionHandler彻底解决了全局统一异常处理 。 当然后面还出现了@RestControllerAdvice这个注解 ， 其实就是@ControllerAdvice和@ResponseBody结晶 。
Spring Boot的异常如何分类？Java中的异常就很多 ， 更别说Spring Boot中的异常了 ， 这里不再根据传统意义上Java的异常进行分类了 ， 而是按照controller进行分类 ， 分为进入controller前的异常和业务层的异常 ， 如下图：
文章插图进入controller之前异常一般是javax.servlet.ServletException类型的异常 ， 因此在全局异常处理的时候需要统一处理 。 几个常见的异常如下：
- NoHandlerFoundException：客户端的请求没有找到对应的controller ， 将会抛出404异常 。
- HttpRequestMethodNotSupportedException：若匹配到了（匹配结果是一个列表 ， 不同的是http方法不同 ， 如：Get、Post等） ， 则尝试将请求的http方法与列表的控制器做匹配 ， 若没有对应http方法的控制器 ， 则抛该异常
- HttpMediaTypeNotSupportedException：然后再对请求头与控制器支持的做比较 ， 比如content-type请求头 ， 若控制器的参数签名包含注解@RequestBody ， 但是请求的content-type请求头的值没有包含application/json ， 那么会抛该异常（当然 ， 不止这种情况会抛这个异常）
- MissingPathVariableException：未检测到路径参数 。 比如url为：/user/{userId} ， 参数签名包含@PathVariable("userId") ， 当请求的url为/user ， 在没有明确定义url为/user的情况下 ， 会被判定为：缺少路径参数
【满屏的try-catch，不瘆得慌？】统一异常处理很简单 ， 这里以前后端分离的项目为例 ， 步骤如下：