[springboot] How to design exception handling and corresponding development specifications (with video)

How to design exception handling and corresponding development specifications

1. An example of the chaos of exception handling

Chaos 1: Only output to the console after catching exceptions

Front-end js-ajax code

$.ajax({
    
    
    type: "GET",
    url: "/user/add",
    dataType: "json",
    success: function(data){
    
    
        alert("添加成功");
    }
});

Back-end business code

try {
    
    
    // do something
} catch (XyyyyException e) {
    
    
    e.printStackTrace();
}

question:

1. The backend directly captures the exception and only prints the log. The user experience is very poor. Once there is an error in the background, the user has no perception and the page is stateless.
2. The back-end only gives the abnormal result of the front-end, and does not give a description of the cause of the exception. The user does not know whether it is an input error or a system bug. Users can't judge that they need to wait a while before operating? Or continue to the next step?
3. If no one pays attention to the server log frequently, no one will find that the system is abnormal.

Chaos II: Chaos Returns

front-end code

$.ajax({
    
    
    type: "GET",
    url: "/goods/add",
    dataType: "json",
    success: function(data) {
    
    
        if (data.flag) {
    
    
            alert("添加成功");
        } else {
    
    
            alert(data.message);
        }
    },
    error: function(data){
    
    
        alert("添加失败");
    }
});

backend code

@RequestMapping("/goods/add")
@ResponseBody
public Map add(Goods goods) {
    
    
    Map map = new HashMap();
    try {
    
    
        // do something
        map.put(flag, true);
    } catch (Exception e) {
    
    
        e.printStackTrace();
        map.put("flag", false);
        map.put("message", e.getMessage());
    }
    reutrn map;
}

question:

1. The data returned by each person has their own specifications. You call the flag and he calls it isOK. Your success code is 0, and its success code is 0000. This causes the backend to write a lot of exception return logic code, and the frontend also requests a set of exception handling logic for each request. A lot of repetitive code.
2. If the front-end and back-end are developed by one person, it is barely usable. If the front-end and back-end are separated, this is a system disaster.

2. How to design exception handling

Friendly to interested parties

1. Back-end developers have a single responsibility, and only need to catch and convert exceptions into custom exceptions and keep throwing them. There is no need to think about the page jump 404 and the design of the data structure of the exception response.
2. It is friendly to front-end personnel, and the data returned from the back-end to the front-end should have a unified data structure and a unified specification. A data structure that cannot respond to each individual. In this process, no more work needs to be done by the back-end developers, and the global exception handler is handed over to handle the conversion from "exception" to "response data structure".
3. User-friendly, the user can clearly know the cause of the exception. This requires custom exceptions, global unified processing, ajax interface requests to respond to a unified exception data structure, and page template requests to uniformly jump to the 404 page.
4. It is friendly to operation and maintenance, persists abnormal information in a reasonable and standardized way, and stores it in the form of logs for easy query.

Why do you want to capture system runtime exceptions and convert them into custom exception throws?
Answer: Because the user does not know what kind of exception similar to ConnectionTimeOutException is, but converting it to a custom exception requires the programmer to translate the runtime exception. For example, there should be a message field in the custom exception, and the back-end programmer should make it clear Use user-friendly language in the message field to describe what happened on the server side.

3. Development Specifications

1. The Controller, Service, and DAO layers intercept exceptions and convert them into custom exceptions, and it is not allowed to intercept exceptions privately. must be thrown out.
2. Unified data response code, use http status code, do not customize. Customization is inconvenient to remember, and HTTP status code programmers know it. But too many programmers can't remember, just use a few within the scope specified by the project team. For example: 200 request success, 400 exception caused by user input error, 500 system internal exception, 999 unknown exception.
3. There is a message attribute in the custom exception, which describes the occurrence of the exception in a user-friendly language and assigns it to the message.
4. It is not allowed to unify the catch of the parent class Exception. It is necessary to divide the catch into sub-classes, so that the exception can be clearly converted into a custom exception and passed to the front end.