满屏的try-catch，不瘆得慌？作者：码猿技术专栏原文链接：目录前言

作者：码猿技术专栏
原文链接：
文章插图
目录

前言
Spring Boot 版本
全局统一异常处理的前世今生
Spring Boot的异常如何分类？
如何统一异常处理？
异常匹配的顺序是什么？
总结

前言软件开发过程中难免遇到各种的BUG ，各种的异常，一直就是在解决异常的路上永不停歇，如果你的代码中再出现try(){...}catch(){...}finally{...}代码块，你还有心情看下去吗？自己不觉得恶心吗？
冗余的代码往往会丧失写代码的动力，每天搬砖似的写代码，真的很难受。今天这篇文章教你如何去掉满屏的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，不瘆得慌？】统一异常处理很简单，这里以前后端分离的项目为例，步骤如下：