How to handle SpringBoot unified interface returns and global exceptions

1. SpringBoot does not use a unified return format

By default, SpringBoot will have the following three return situations.

1.1 Use string to return

@GetMapping("/getUserName")
public String getUserName(){
    return "HuaGe";
}

Call the interface to return the result:

HuaGe

1.2 Use entity class to return

@GetMapping("/getUserName")
public User getUserName(){
    return new User("HuaGe",18,"男");
}

Call the interface to return the result:

{
  "name": "HuaGe",
  "age": "18",
  "性别": "男", 
}

1.3 Return under abnormal circumstances

@GetMapping("/getUserName")
public static String getUserName(){
    HashMap hashMap = Maps.newHashMap();
    return hashMap.get(0).toString();
}

Simulates a null pointer exception. Without any exception handling, you can look at the default return result of SpringBoot:

{
    "timestamp": "2021-08-09T06:56:41.524+00:00",
    "status": 500,
    "error": "Internal Server Error",
    "path": "/sysUser/getUserName"
}

For the above situations, if the entire project does not define a unified return format and five backend developers define five return formats, not only will the code be bloated, the front-end and back-end docking efficiency will be low, but there will also be some inconsistencies. When certain situations occur, such as the front-end directly displaying exception details, etc., this gives the user a very poor experience.

2. Basic gameplay

The most common thing in projects is to encapsulate a tool class. The field information that needs to be returned is defined in the class, and the interface information that needs to be returned to the front end is encapsulated through this class. , this can solve the problem of inconsistent return formats.

2.1 Parameter Description

• code： Status code, the background can maintain a unified set of status codes;

• message: Description information, prompt information of success/failure of interface call;

• data: Return data.

2.2 Process Description

• New Result class

public class Result<T> {
    
    private int code;
    
    private String message;
    
    private T data;

    public Result() {}
    public Result(int code, String message) {
        this.code = code;
        this.message = message;
    }
    
    /**
     * 成功
     */
    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<T>();
        result.setCode(ResultMsgEnum.SUCCESS.getCode());
        result.setMessage(ResultMsgEnum.SUCCESS.getMessage());
        result.setData(data);
        return result;
    }

    /**
     * 失败
     */
    public static <T> Result<T> error(int code, String message) {
        return new Result(code, message);
    }
}

Define the return status code

public enum ResultMsgEnum {
    SUCCESS(0, "成功"),
    FAIL(-1, "失败"),
    AUTH_ERROR(502, "授权失败!"),
    SERVER_BUSY(503, "服务器正忙，请稍后再试!"),
    DATABASE_OPERATION_FAILED(504, "数据库操作失败");
    private int code;
    private String message;

    ResultMsgEnum(int code, String message) {
        this.code = code;
        this.message = message;
    }
    public int getCode() {
        return this.code;
    }
    
    public String getMessage() {
        return this.message;
    }
}

• Usage

The above two steps define Data return format and status code , next we need to see how to use it in the interface.

@GetMapping("/getUserName")
public Result getUserName(){
    return Result.success("huage");
}

The calling result is as follows. You can see that it is the parameter type we defined in Result.

{
    "code": 0,
    "message": "成功",
    "data": "huage"
}

Although writing this way can meet daily needs, and I believe many friends use it this way, but if we have a large number of interfaces, then use Result.success## in each interface # to package the returned information will add a lot of repeated code, which is not elegant enough and even embarrassing to show off. There must be a way to improve the code again and achieve the optimal solution.

3. Advanced Usage

After learning the basic usage, let’s look at the ultimate version, which mainly uses the following two knowledge points. The usage is simple, whether it is used to teach girls, or Giving guidance to young ladies is a necessary skill.

3.1 Class introduction

• ResponseBodyAdvice: This interface is provided by SpringMVC 4.1, which allows the execution of @ResponseBody Customized return data is used to encapsulate unified data format returns;

• @RestControllerAdvice: This annotation is an enhancement to the Controller and can globally capture thrown exceptions .

3.2 Usage instructions

• Create a new

  ResponseAdvice class;

• implementation

  ResponseBodyAdvice interface, implements supports, beforeBodyWrite methods;

• This class is used to uniformly encapsulate the return of the interface in the controller result.

@RestControllerAdvice
public class ResponseAdvice implements ResponseBodyAdvice<Object> {
    @Autowired
    private ObjectMapper objectMapper;

    /**
     * 是否开启功能 true：是 
     */
    @Override
    public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) {
        return true;
    }

    /**
     * 处理返回结果
     */
    @Override
    public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) {
        //处理字符串类型数据
        if(o instanceof String){
            try {
                return objectMapper.writeValueAsString(Result.success(o));
            } catch (JsonProcessingException e) {
                e.printStackTrace();
            }
        }
        return Result.success(o);
    }
}

We can test it through the

getUserName interface, and we will find that the result returned by using Result directly is consistent.

However, careful friends must have noticed that in

ResponseAdvice we all use Result.success(o) to process results, for error type results Not processed. Let's take a look, what is the return result when an exception occurs? Continuing to use the above HashMap null pointer exception code, the test results are as follows:

{
    "code": 0,
    "message": "成功",
    "data": {
        "timestamp": "2021-08-09T09:33:26.805+00:00",
        "status": 405,
        "error": "Method Not Allowed",
        "path": "/sysUser/getUserName"
    }
}

Although there is no problem with the format, the specific data in the code and data fields are unfriendly or incorrect. Failure to handle these matters well will seriously affect one's tall image in the front-end sister's mind, which will never be tolerated.

3.3 Global Exception Handler

When we encountered an exception in the past, the first thing that came to mind was try..catch..final. However, this method will lead to a lot of code duplication. Problems such as difficulty in maintenance and bloated logic are not the results we want.

The global exception handling method we are going to use today is relatively simple to use. First, add a new class and add the

@RestControllerAdvice annotation. Brother Hua has already introduced the function of this annotation, so I won’t go into details.

@RestControllerAdvice
public class CustomerExceptionHandler {
    
}

If we have an exception type that we want to intercept, add a new method and modify it with the

@ExceptionHandler annotation, and the annotation parameter is the target exception type.

For example: When an Exception occurs in the interface in the controller, it will enter the

Execption method to capture it, convert the messy exception information into the specified format and hand it over to ResponseAdviceMethod encapsulates the data in a unified format and returns it to the front-end partner.

@RestControllerAdvice
@Slf4j
public class CustomerExceptionHandler {

    @ExceptionHandler(AuthException.class)
    public String ErrorHandler(AuthorizationException e) {
        log.error("没有通过权限验证！", e);
        return "没有通过权限验证！";
    }

    @ExceptionHandler(Exception.class)
    public Result Execption(Exception e) {
        log.error("未知异常！", e);
        return Result.error(ResultMsgEnum.SERVER_BUSY.getCode(),ResultMsgEnum.SERVER_BUSY.getMessage());
    }
}

再次调用接口getUserName查看返回结果，会发现还是有一些问题，因为我们在CustomerExceptionHandler中已经将接口返回结果封装成Result类型，而代码执行到统一结果返回类ResponseAdvice时，又会结果再次封装，就出现了如下问题。

{
    "code": 0,
    "message": "成功",
    "data": {
        "code": 503,
        "message": "服务器正忙，请稍后再试!",
        "data": null
    }
}

3.4 统一返回结果处理类最终版

解决上述问题非常简单，只要在beforeBodyWrite中增加一条判断即可。

@RestControllerAdvice
public class ResponseAdvice implements ResponseBodyAdvice<Object> {
    @Autowired
    private ObjectMapper objectMapper;

    /**
     * 是否开启功能 true:开启
     */
    @Override
    public boolean supports(MethodParameter methodParameter, Class<? extends HttpMessageConverter<?>> aClass) {
        return true;
    }

    /**
     * 处理返回结果
     */
    @Override
    public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class<? extends HttpMessageConverter<?>> aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) {
        //处理字符串类型数据
        if(o instanceof String){
            try {
                return objectMapper.writeValueAsString(Result.success(o));
            } catch (JsonProcessingException e) {
                e.printStackTrace();
            }
        }
        //返回类型是否已经封装
        if(o instanceof Result){
            return o;
        }
        return Result.success(o);
    }
}

The above is the detailed content of How to handle SpringBoot unified interface returns and global exceptions. For more information, please follow other related articles on the PHP Chinese website!