为什么要使用全局异常处理？
- 减少冗余代码： 在不使用全局异常处理器的情况下，项目中各层可能会出现大量的try {…} catch {…} finally {…}代码块，这些代码块不仅冗余，还影响代码的可读性。全局异常处理器允许我们在一个独立的类中定义对所有控制器异常的处理机制，从而消除大部分try-catch块。
- 统一异常处理： 全局异常处理器可以将异常按阶段（如进入Controller前的异常和Service层异常）进行分类处理，提供统一的异常处理策略。
- 自定义异常处理： 对于自定义的异常，使用全局异常处理器可以更容易地进行捕获和处理，而不是在每个可能抛出异常的地方都写一遍处理逻辑。
- 客户端友好性： 直接抛出异常给客户端可能会导致客户端无法理解异常信息。全局异常处理器允许我们将异常转换为客户端可理解的格式（如JSON响应），提高用户体验。
总结：
全局异常处理器的使用可以显著提高Spring Boot项目的代码质量和可维护性，减少冗余代码，提高代码的可读性和可维护性，统一异常处理策略，并提高客户端体验。因此，在Spring Boot项目中，使用全局异常处理器是一个值得推荐的做法。
代码实战
首先我们需要在项目中创建一个全局异常处理器类，比如叫 GlobalExceptionHandler，在该类上面需要加上 @RestControllerAdvice 注解表示这是一个全局异常处理器，代码示例：
import lombok.SneakyThrows;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.util.StringUtils;
import org.springframework.validation.BindingResult;
import org.springframework.validation.FieldError;
import org.springframework.web.bind.MethodArgumentNotValidException;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;
import javax.servlet.http.HttpServletRequest;
import java.util.Optional;
/**
* 全局异常处理器
*/
@RestControllerAdvice
public class GlobalExceptionHandler {
public final Logger logger = LoggerFactory.getLogger(this.getClass());
/**
* 拦截参数验证异常
*/
@SneakyThrows
@ExceptionHandler(value = MethodArgumentNotValidException.class)
public AjaxResult validExceptionHandler(HttpServletRequest request, MethodArgumentNotValidException ex) {
BindingResult bindingResult = ex.getBindingResult();
FieldError firstFieldError = CollectionUtil.getFirst(bindingResult.getFieldErrors());
String exceptionStr = Optional.ofNullable(firstFieldError)
.map(FieldError::getDefaultMessage)
.orElse(StrUtil.EMPTY);
logger.error("[{}] {} [ex] {}", request.getMethod(), getUrl(request), exceptionStr);
return AjaxResult.error(exceptionStr);
}
/**
* 拦截业务异常
* BusinessServiceException 是一个自定义异常，以你们项目中的自定义异常为准，如果没有可以不写
*/
@ExceptionHandler(value = {BusinessServiceException.class})
public AjaxResult handleBusinessException(HttpServletRequest request, BusinessServiceException ex){
String exceptionStr = ex.getMessage();
logger.error("[{}] {} [ex] {}", request.getMethod(), getUrl(request), exceptionStr);
return AjaxResult.error(exceptionStr);
}
/**
* 拦截未捕获异常
*/
@ExceptionHandler(Throwable.class)
public AjaxResult defaultErrorHandler(HttpServletRequest request, Throwable throwable) {
logger.error("[{}] {} ", request.getMethod(), getUrl(request), throwable);
return AjaxResult.error(throwable.getMessage());
}
private String getUrl(HttpServletRequest request) {
if (StringUtils.isEmpty(request.getQueryString())) {
return request.getRequestURL().toString();
}
return request.getRequestURL().toString() + "?" + request.getQueryString();
}
}
到这里，全局异常处理器就已经写完了，接下来就是验证环节。我会依次验证每一个异常场景是否可以成功拦截。
在验证之前，我们先来看一张图：
上面这张图片大家应该都很熟悉，这就是在不对接口中的异常进行处理时 SpringBoot 默认返回的页面，如果我们的异常处理器生效了，那么返回的就应该是我们封装好的数据。
验证 MethodArgumentNotValidException 异常
在验证 MethodArgumentNotValidException 异常前，需要先说明一下该异常常见的触发场景：
- 数据转换问题：当客户端传递的数据类型无法正确转换为方法参数的类型时，会发生数据转换问题，导致MethodArgumentNotValidException异常。这通常发生在使用@RequestBody注解处理JSON请求体时，如果JSON格式不正确或无法映射到目标对象，就会抛出此异常。
- 错误的验证注解： 如果在实体类中对属性使用了不符合验证需求的注解，如@NotNull、@Size等，并且请求中的数据不符合这些注解指定的规则，那么在Spring MVC将请求参数解析为控制器方法参数时会触发校验，并抛出MethodArgumentNotValidException异常。
- 未通过校验的参数： 当使用@Valid或@Validated注解对方法参数进行校验时，如果参数不符合校验规则（如非空、长度、格式等），会抛出MethodArgumentNotValidException异常。例如，一个表单提交到Controller时，如果表单中的某个字段不符合校验规则，则会抛出此异常。
接下来我们创建一个 UserEntity 类做为方法参数用来测试：
import lombok.Data;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;
@Data
public class UserEntity {
@NotNull(message = "用户ID不能为空")
private Long userId;
@NotNull(message = "用户名不能为空")
@Size(min = 2, max = 30, message = "用户名长度必须在2到30个字符之间")
private String username;
}
// 注意，这个方法我们并没有采取任何 try catch 操作
@PostMapping("/test")
public AjaxResult Test(HttpServletRequest request, @RequestBody @Valid UserEntity userEntity) {
Map<String,Object> model = new HashMap<String,Object>();
String planCode = request.getParameter("planCode");
String planDefineId = request.getParameter("planDefineId");
if (StringUtils.isBlank(planDefineId) || StringUtils.isBlank(planCode)) {
throw new BusinessServiceException("参数不可以为空！");
}
// 获取信息
String planName = retailProductCommon.getproductName(planCode, planDefineId);
model.put("planName", planName);
return AjaxResult.success(model);
}
这里我们使用 PostMan 工具去请求这个接口，并设置一个不满足要求的参数，看下是否会以为抛错导致程序中断。请求结果：
可以发现，正常返回错误信息给客户端了，并没有直接抛500。
验证自定义异常
验证 BusinessServiceException 异常也很简单，我们将上面 UserEntity 的参数补全，但是代码中为空会抛错的那个两个参数我们不传，看下会有什么结果。请求结果：
这里同样是我们自定义的返回对象，并不是SpringBoot默认的500页面，所以验证成功。
验证其他异常
接下来我们在 test 接口中手动写一个异常代码出来，比如int num = 1/0当代码执行到这里的时候会抛出 / by zero，我们看下结果如何，会不会被 defaultErrorHandler 方法拦截：
这里同样是我们自定义的返回对象，并不是SpringBoot默认的500页面，所以验证成功。
