Background analysis In the development of a project, whether it is to the underlying data logic operation process, or the business logic processing process, or the control logic processing process, it is inevitable to meet a variety of predictable, unpredictable exceptions. Handling exceptions well can protect the system and greatly improve the user experience.

Exception Handling Analysis Java projects can handle exceptions in one of two ways, either by performing a TryCatch or by performing a Throw (thrown to another object for handling). In either case, the goal is to get our system to respond to the exception. But the question now is how can we make this feedback code simple, intuitive and friendly to write.

Java Project Exception Handling Specification We usually follow certain design specifications when handling exceptions, such as:

First: the exception caught must match exactly the exception thrown, or the catching exception is the parent type of the exception thrown. Second: Avoid throwing RuntimeException directly, let alone Exception or Throwable, and use a custom Exception with business meaning (such as ServiceException). Third: After the exception is caught, it must be handled (for example, logging). If you don’t want to handle it, you need to throw the exception to its caller. Fourth: The outermost layer of logic must handle exceptions and turn them into something that the user can understand. No. 5: Don’t Repeat Yourself (the Day Principle).

The first approach to exception handling under SpringBoot projects is to try directly in the Controller method

try{
.....
}catch(Exception e){
.....
}

If every method in the Controller had to do this, it would be too much code and too reusable to maintain.

The second way is to define one or more exception handling methods in the Controller. The key code is as follows:

@ExceptionHandler(RuntimeException.class)
@ResponseBody
public String doHandleException(RuntimeException e){
    log.error("exception {}",e.getMessage());
    return e.getMessage();
}

All exception handling methods need to be described using @ExceptionHandler and state the types of exceptions that the method it describes can handle. But for this In other words, it can only handle RuntimeExceptions or exceptions of subclass type that occur in each method of the current Controller. If the same exception handling method is required in multiple Controller classes, it is not possible to define the exception handling method directly in the Controller class It’s a good choice.

The third method: Define the global exception handling class and exception handling method in the control logic layer. The key code is as follows:

@SLF4J //@ResponseBody //@ControllerAdvice @RestControllerAdvice public class GlobalExceptionHandler {Exception handler @ExceptionHandler(IllegalArgumentException.class) public String doHandleException(IllegalArgumentException e){ log.error("IllegalArgumentException.exception {}",e.getMessage()); return e.getMessage(); @ExceptionHandler(RuntimeException.class) public String doHandleException(RuntimeException E){ log.error("RuntimeException.exception {}",e.getMessage()); return e.getMessage(); }

The @RestControllerAdvice annotation describes a global exception handling class. When an exception in a control layer method is not caught by itself and no internal exception handling method is defined, the underlying layer will find the global exception handling class by default and call the corresponding exception handling method to handle the exception.