在Java项目中，引入【全局异常处理器】

目录

一.为什么引入全局异常处理器（目前项目碰到了什么问题）？

1.问题描述

2.与预期的差别

3.解决方案

二.解决上述问题

1.定义【业务异常类】

2.在serviceImpl层，手动抛出【违反唯一性约束】这个异常

3.定义【全局异常处理器】

4.修改userController层的代码

三.展示效果

四.重点理解【全局异常处理器】的优点

1.项目引入了全局异常处理器以后，就不用在controller里面判断insert语句的影响行数了

2.引入全局异常处理器后，可以使得请求异常时的响应数据可读性非常强。

3.引入全局异常处理器后，后端产生异常时不会在控制台输出大片异常信息。

4.总结大致流程

五.前端如何接收后端的异常响应数据

1.修改封装axios的代码

2.使用封装好的axios的api请求时，要求使用try/catch捕获出现的异常

3.展示效果

4.总结

结语

---

一.为什么引入全局异常处理器（目前项目碰到了什么问题）？

1.问题描述

        我们在添加一个系统用户时，要求用户名（username字段）必须是唯一的，即不能重复。如果重复了，那么insert语句不会返回0（之前我们是这么认为的），而是直接令后端报错。如下：

使用apiFox添加一个系统用户： 

去后端控制台查看报错：

可见此时是因为违反了user表的username字段的唯一约束（unique）。

2.与预期的差别

        我的初衷是：添加一个系统用户时，如果添加成功，就返回影响行数1；如果添加失败，就返回影响行数0。 

        这样就能在controller层中，根据影响行数来决定返回给前端什么响应体。

        如下：

        userServiceImpl层：

        userController层： 

        重点来了：上述所预想的一切，都不成立。因为当insert语句执行失败时，根本就不返回影响行数0，而是直接使后端崩塌，响应给前端的数据也是可读性极差。 

3.解决方案

         此时就需要定义【业务异常】和【全局异常处理器】来包容上述的错误。

        就好比insert语句执行失败时，扔出一颗炸弹，但没关系，我们直接使用全局异常处理器，来吸收即可。

二.解决上述问题

1.定义【业务异常类】

        该业务异常类，就包括我们上面提到的违反了唯一约束的这种异常。

        而且以后我们项目中出现了其他的业务异常，也可以用该类来接收。

        第一步：创建Exception目录，用来存放自定义异常类和全局异常处理器。

        第二步：在 Exception目录下，创建【业务异常类】。

2.在serviceImpl层，手动抛出【违反唯一性约束】这个异常