商城首页欢迎来到中国正版软件门户

您的位置: 首页 > 文章列表 > 编程开发 > SpringBoot全局异常处理与参数校验功能实现

SpringBoot全局异常处理与参数校验功能实现

  发布于2026-07-08 阅读(0)

扫一扫,手机访问

后端接口报错,要是直接让异常往外抛,前端收到的要么是一大段 Tomcat 默认的 HTML 错误页,要么是乱七八糟的堆栈信息。前端同学一看就懵了——这到底是啥错?该提示用户什么?

SpringBoot全局异常处理与参数校验功能实现

所以得有一层兜底:不管哪层出了什么岔子,返回给前端的东西始终是统一格式的 JSON——有错误码、有错误信息,前端拿到手就能稳稳地做判断和处理。

参数校验也得一起安排上。Controller 里别写一堆 if (xxx == null),用注解声明规则,校验不通过直接抛异常,再由全局处理器统一拦截、统一返回。代码干净,逻辑也清晰。

引入依赖

@ControllerAdvice@ExceptionHandler 这些都在 spring-boot-starter-web 里,如果你项目已经用了 Web 模块,这部分就不用重复加了。

但参数校验的依赖需要单独拎出来:


    org.springframework.boot
    spring-boot-starter-validation

注意一下版本差异:Spring Boot 2.x 时代,validation 是内嵌在 spring-boot-starter-web 里的,到了 3.x 就被拆出来了。如果不加这个依赖,@NotBlank@Valid 这些注解不会报编译错误,但运行时校验根本不生效——加了个寂寞,所有参数直接放行。

第一步:搭异常体系

common

先搭两个基础的东西:异常接口 + 异常类。这两个放在 common 模块,全项目都能复用。

BaseExceptionInterface

public interface BaseExceptionInterface {
    String getErrorCode();
    String getErrorMessage();
}

一个很简单的接口,它就规定一件事:异常必须包含错误码和错误信息。后面我们的枚举实现它,BizException 也依赖它,所有东西都围绕这个约定来走。

BizException

BizException 代表业务异常,每个模块都可能出现,所以定义在 common 里最合适。

@Getter
@Setter
public class BizException extends RuntimeException {
    private String errorCode;
    private String errorMessage;
    public BizException(BaseExceptionInterface baseExceptionInterface) {
        this.errorCode = baseExceptionInterface.getErrorCode();
        this.errorMessage = baseExceptionInterface.getErrorMessage();
    }
}

继承 RuntimeException,有两个好处:抛的时候不用在方法签名上加 throws,Spring 对运行时异常默认也会做事务回滚。构造参数只接收 BaseExceptionInterface,不让你随便写 new BizException("随便写的错")——所有异常必须提前在枚举里定义好,方便统一管理。

具体业务模块

接下来定义你这个模块可能有哪些异常。

ResponseCodeEnum

@Getter
@AllArgsConstructor
public enum ResponseCodeEnum implements BaseExceptionInterface {
    // 通用异常
    SYSTEM_ERROR("AUTH-10000", "出错啦,后台小哥正在努力修复中..."),
    PARAM_NOT_VALID("AUTH-10001", "参数错误"),
    // 业务异常往后加
    ;
    private final String errorCode;
    private final String errorMessage;
}

这里有个小巧妙:BaseExceptionInterface 定义的 getErrorCodegetErrorMessage 两个方法,枚举里定义了两个变量,加上 @Getter,刚好就把接口方法给实现了。巧不巧?

要点说明
实现 BaseExceptionInterface枚举实例可以直接丢进 BizException 的构造参数
错误码前缀AUTH 代表这个模块,不同模块用不同前缀,比如订单模块用 ORDER-20000,一眼就能看出问题出在哪
后面加什么登录失败、用户不存在、权限不足……随着业务迭代,直接在枚举里加新的即可

抛一个业务异常就一句话:

throw new BizException(ResponseCodeEnum.SYSTEM_ERROR);

三者关系

BizException 的构造参数是 BaseExceptionInterface(接口),不是 ResponseCodeEnum(具体枚举)。所以层级关系是这样的:

BizException 构造参数
        ↓ 依赖
BaseExceptionInterface(接口:规定必须有 errorCode + errorMessage)
        ↑ 实现
ResponseCodeEnum(枚举:集中管理所有错误码)
  • 接口 起约定作用:不管哪个模块、哪个枚举,只要你实现了这两个 getter,就能丢进 BizException
  • 枚举 起集中管理作用:所有错误码一处定义,不散落
  • BizException 只认接口不认枚举,auth 模块的 AuthResponseCodeEnum、order 模块的 OrderResponseCodeEnum,只要实现了接口,都能用

如果直接用 new BizException(String, String),错误码就会散落在项目各个角落,改一个提示语得全项目搜索,想看看系统里有哪些错误码更是无从下手。

第二步:全局异常处理器

@ControllerAdvice
@Slf4j
public class GlobalExceptionHandler {
    /** 业务异常 */
    @ExceptionHandler({ BizException.class })
    @ResponseBody
    public Response handleBizException(HttpServletRequest request, BizException e) {
        log.warn("{} request fail, errorCode: {}, errorMessage: {}",
                request.getRequestURI(), e.getErrorCode(), e.getErrorMessage());
        return Response.fail(e);
    }
    /** 参数校验失败 */
    @ExceptionHandler({ MethodArgumentNotValidException.class })
    @ResponseBody
    public Response handleMethodArgumentNotValidException(
            HttpServletRequest request, MethodArgumentNotValidException e) {
        String errorCode = ResponseCodeEnum.PARAM_NOT_VALID.getErrorCode();
        BindingResult bindingResult = e.getBindingResult();
        StringBuilder sb = new StringBuilder();
        Optional.ofNullable(bindingResult.getFieldErrors()).ifPresent(errors -> {
            errors.forEach(error ->
                sb.append(error.getField())
                  .append(" ")
                  .append(error.getDefaultMessage())
                  .append(", 当前值: '")
                  .append(error.getRejectedValue())
                  .append("'; ")
            );
        });
        log.warn("{} request error, errorCode: {}, errorMessage: {}",
                request.getRequestURI(), errorCode, sb.toString());
        return Response.fail(errorCode, sb.toString());
    }
    /** 其他未捕获的异常——兜底 */
    @ExceptionHandler({ Exception.class })
    @ResponseBody
    public Response handleOtherException(HttpServletRequest request, Exception e) {
        log.error("{} request error", request.getRequestURI(), e);
        return Response.fail(ResponseCodeEnum.SYSTEM_ERROR);
    }
}

三个关键注解

注解干什么的
@ControllerAdvice全局增强,所有 Controller 的异常都会被这里的 @ExceptionHandler 拦截
@ExceptionHandler声明这个方法专门处理哪种类型的异常
@ResponseBody返回的内容直接序列化为 JSON,不走视图模板

三层兜底结构

Exception(其他所有异常)         ← 第三层:保底,全拦住了
  └─ MethodArgumentNotValidException  ← 第二层:参数校验
  └─ BizException                      ← 第一层:业务异常

Spring 的匹配规则是找最精确的。如果抛的是 BizException,只走第一个 handler;抛的是 MethodArgumentNotValidException,走第二个;其他任何没被前两个匹配到的异常,都掉进第三个兜底。三层覆盖,不会有漏网之鱼。

注意看日志级别:BizException 用的 log.warn,因为它是业务"可预期"的错,不需要大惊小怪。最后那个 Exceptionlog.error 并打印了堆栈,因为这是真正该修 bug 的异常。

第三步:参数校验

上面那个 MethodArgumentNotValidException 是什么时候抛的?当加了 @Valid 的入参校验不通过时

在实体类属性上加校验注解

@Data
public class User {
    @NotBlank(message = "昵称不能为空")
    private String nickName;
    private LocalDateTime createTime;
}

在 Controller 方法参数里加 @Valid

@PostMapping("/test2")
@ApiOperationLog(description = "测试接口2")
public Response test2(@Valid @RequestBody User user) {
    return Response.success(user);
}

注意 @Valid 是加在方法参数上的,不是加在类上。两个动作缺一不可:

  • 类上没有 @NotBlank → 不会校验,什么都能通过
  • 方法参数没有 @Valid → 不会触发校验,注解成了摆设

校验错误信息是怎么拼出来的?

GlobalExceptionHandler 里的 handleMethodArgumentNotValidException 遍历了 bindingResult.getFieldErrors(),把每条错误的字段名、校验描述、实际收到的值拼接在一起:

sb: "nickName 昵称不能为空, 当前值: ''; "

这样前端一看到就知道是哪个字段出问题、为什么不通过、实际传了什么值,排查效率高不少。

常用校验注解

注解校验规则
@NotBlank不能为 null 且不能是空字符串(""不行," "也不行)
@NotNull不能为 null(但 "" 可以通过)
@NotEmpty不能为 null 且不能是空集合或空字符串
@Email必须是邮箱格式
@Size(min, max)字符串或集合的长度范围
@Min / @Max数字的最小值/最大值
@Pattern(regexp)自定义正则校验

选哪个要看业务场景。比如昵称不允许空字符串,用 @NotBlank 而不是 @NotNull,因为 @NotNull 允许 "" 通过,这个差别很关键。

完整流程串联

以一个参数校验失败的请求为例,整个调用链路是这样的:

  1. 前端 POST /test2,body 为 { "nickName": "" }
  2. Spring 将 JSON 序列化为 User 对象
  3. @Valid 触发校验 → @NotBlank 校验失败
  4. Spring 抛出 MethodArgumentNotValidException
  5. @ControllerAdvice 中的 handleMethodArgumentNotValidException 将其拦截
  6. 遍历错误字段,拼出 "nickName 昵称不能为空, 当前值: ''; "
  7. 返回 Response.fail("AUTH-10001", "...") → 最终输出为 JSON

前端从头到尾拿到的都是统一结构,一个 if (response.success) 就能判断是否正常,处理起来非常清爽。

如何使用业务异常

想手动中断一个请求、返回错误信息给前端,直接这样写:

// 不满足条件,直接抛
if (user == null) {
    throw new BizException(ResponseCodeEnum.SYSTEM_ERROR);
}

ResponseCodeEnum 里加新的异常码:

// 通用异常
SYSTEM_ERROR("AUTH-10000", "出错啦,后台小哥正在努力修复中..."),
PARAM_NOT_VALID("AUTH-10001", "参数错误"),
// 业务异常
LOGIN_FAILED("AUTH-20001", "用户名或密码错误"),
USER_NOT_FOUND("AUTH-20002", "用户不存在"),
UNAUTHORIZED("AUTH-20003", "没有访问权限"),
;

然后在代码里直接抛:

throw new BizException(ResponseCodeEnum.LOGIN_FAILED);

所有异常码统一管理、统一抛出、统一处理,整个异常体系就非常规整了。

本文转载于:https://www.jb51.net/program/367002f4j.htm 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。
  • using namespace 使用中遇到的问题怎么解决 正版软件
    using namespace 使用中遇到的问题怎么解决
    命名空间的基本概念与常见引入问题在C++等编程语言中,命名空间(namespace)是一种将代码标识符(如变量、函数、类名)封装在特定名称下的机制,其主要目的是避免命名冲突,尤其是在大型项目或使用多个第三方库时。使用“using namespace”指令可以将指定命名空间中的所有名称引入当前作用域,
    11天前 0
  • c语言函数递归 实操经验总结:这些技巧很实用 正版软件
    c语言函数递归 实操经验总结:这些技巧很实用
    理解递归的基本原理在C语言中,递归是一种函数调用自身的编程技术。要掌握它,首先需要理解其核心思想:将一个复杂的大问题,分解为一个或几个与原问题相似但规模更小的子问题,直到子问题足够简单,可以直接求解。这个过程通常包含两个关键部分:递归出口和递归体。递归出口定义了问题何时不再继续分解,即最简单、可直接
    11天前 0
  • c语言函数递归 怎么选?常见方案对比分析 正版软件
    c语言函数递归 怎么选?常见方案对比分析
    递归函数的基本概念与适用场景在C语言编程中,递归是一种函数调用自身的编程技巧。它并非适用于所有问题,但在处理某些具有自相似结构的问题时,能提供极其清晰和优雅的解决方案。递归的核心思想是将一个大规模问题分解为一个或多个同类型但规模更小的子问题,直到子问题简单到可以直接求解。典型的适用场景包括树形结构的
    11天前 0
  • Objective-C 内存管理入门:从 alloc 到 dealloc 的生命周期详解 正版软件
    Objective-C 内存管理入门:从 alloc 到 dealloc 的生命周期详解
    理解内存管理的基石在Objective-C的编程世界中,内存管理是开发者必须掌握的核心技能之一。它直接关系到应用的性能、稳定性与资源利用效率。与一些采用自动垃圾回收机制的语言不同,Objective-C在很长一段时间里,依赖一套基于引用计数的、需要开发者部分介入的管理规则。这套规则的核心思想是明确的
    11天前 0
  • 如何正确使用 dealloc 以避免 iOS 应用中的内存泄漏 正版软件
    如何正确使用 dealloc 以避免 iOS 应用中的内存泄漏
    理解 dealloc 的角色与时机在 iOS 应用开发中,内存管理是保障应用性能与稳定性的基石。dealloc 方法是 Objective-C 中对象生命周期结束时的关键回调,它标志着对象即将被系统回收内存。正确理解其触发时机至关重要:当一个对象的引用计数降为零时,运行时系统会自动调用该对象的 de
    11天前 0