当前位置：首页 > news >正文

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

news 来源：原创 2025/6/19 21:20:55

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

1.问题描述

2.与预期的差别

3.解决方案

二.解决上述问题

1.定义【业务异常类】

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

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

4.修改userController层的代码

三.展示效果

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

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

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

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层，手动抛出【违反唯一性约束】这个异常

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

全局异常处理器，得益于spring。我们可以在全局异常处理器中，进行捕获某种异常并进行对应操作。从而来优化响应数据、防止后端崩塌（其实是美化后端控制台）。

在exception目录下，创建全局异常处理器。

package com.neuedu.his.Exception;

import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.HashMap;
import java.util.Map;


@ControllerAdvice//该注解可以自动捕获我们刚才抛出的异常
public class GlobalExceptionHandler {

    //处理自定义异常：【业务异常BusinessException】
    @ExceptionHandler(BusinessException.class)//专门处理业务异常类BusinessException
    @ResponseBody//表示我们要将该方法的返回值转为JSON格式返回给前端
    public ResponseEntity<Map<String, Object>> handleBusinessException(BusinessException e){
        Map<String, Object> response = new HashMap<>();
        response.put("code", 409);
        response.put("message", e.getMessage());
        return new ResponseEntity<>(response, HttpStatus.CONFLICT);
    }

    //处理其他异常
    @ExceptionHandler(Exception.class)
    @ResponseBody
    public ResponseEntity<Map<String, Object>> handleException(Exception e){
        Map<String, Object> response = new HashMap<>();
        response.put("code", 500);
        response.put("message", "系统内部错误，请稍后重试");
        return new ResponseEntity<>(response, HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

4.修改userController层的代码

三.展示效果

成功的情况：

异常情况1：违反了数据库字段唯一性（业务异常）

异常情况2：其他异常

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

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

如下：我们在userController层中，没有判断insert语句的影响行数的情况下，就返回了成功信息。

这是因为，代码能走到这里，说明userService没有抛出任何异常，也就间接说明了我们的添加用户业务没有任何问题，因此结果肯定是添加成功，因此就可以直接返回成功信息。

因此以后我们项目引入全局异常处理器以后，在controller层可以直接调用完service层后直接返回成功信息。

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

引入全局异常处理器之前，请求异常时的响应信息：

引入全局异常处理器之后，请求异常时的响应信息：

如下图：这两种异常请求下的响应数据，可读性都十分强，比原来的大坨字母强多了。

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

引入全局异常处理器之前，产生异常时控制台的样貌：

引入全局异常处理器之后，产生异常时控制台的样貌：

4.总结大致流程

①定义【自定义异常类】和【全局异常处理器】

②手动在serviceIml层抛出异常

③【全局异常处理器】自动捕获上面抛出的异常，并进行响应消息处理。

④如果serviceImpl层没抛出异常，则响应消息由controller层返回；

如果serviceImpl层抛出了一场，则响应消息由【全局异常处理器】的某个方法返回。