首页 开发教程 Spring Boot全局异常处理的背后的故事

Spring Boot全局异常处理的背后的故事

开发教程 2025年12月4日
697 浏览

01 引言

SpringBoot全局异常处理已经被各大技术大牛讲烂了,使用@ControllerAdvice@ExceptionHandler来处理全局异常。本节我们将借鉴框架提供的异常处理机制,完善全局异常的处理,并聊聊背后的故事。

02 全局异常处理重现

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(BindException.class)
    public ResponseEntity<Map> handleValidationExceptions(BindException ex) {
        return ResponseEntity.badRequest().body(buildErrors(ex.getFieldError().getDefaultMessage()));
    }

    @ExceptionHandler(RuntimeException.class)
    public ResponseEntity<Map> handleException(RuntimeException ex) {
        return ResponseEntity.badRequest().body(buildErrors(ex.getMessage()));
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<Map> handleException(Exception ex) {
        return ResponseEntity.badRequest().body(buildErrors(ex.getMessage()));
    }

    private Map buildErrors(String msg) {
        Map body = new HashMap();
        body.put(\"success\", false);
        body.put(\"msg\", msg);
        body.put(\"data\", null);
        return body;
    }
}

@ControllerAdviceSpring MVC 中一个非常强大且实用的注解,它的核心作用是提供全局的、跨多个控制器的增强处理。就像一个\”全局拦截器\”或\”切面\”。

@ExceptionHandler主要用来处理对应的异常,其中@ExceptionHandler(Exception.class)是兜底异常,匹配不到的异常最终都会走到里面。

在很多博主分享的文章中,都会说这里需要定义所有需要处理的异常。但是具体有哪些异常,始终没有参考的东西。

按照小编的设想,异常的处理如果只关心异常的信息提示,那只要分出e.getMessage()能不能取出异常信息,凡是不能取出的都需要特殊处理,如:

  • BindException

    e.getBindingResult().getFieldErrors()[0].getDefaultMessage

  • MissingServletRequestParameterException

    e.getParameterName()获取缺失的字段。

其他的只需要兜底的异常即可。

03 框架自带全局异常

全局异常处理的异常也有被有些大牛单独列出来过,心想这么多异常谁能记住。我只关心能不能取到异常信息就好。

直到前两天整理SpringBoot配置的时候,看到了SpringBoot框架自带了一个异常处理器,几乎枚举了所有常见的异常.

ResponseEntityExceptionHandler

org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler

如果打算细分的朋友,可以参考这个类定制属于自己的异常处理器了。

04 异常解析器

原本全局异常的处理,上面的内容已经足够了。但是分享SpringBootWebMvcConfigurer配置项的时候,才发现原来配置项也可以进行异常的统一处理。

这两个方法在配置项中已经介绍的很清楚了,这里不再赘述。

我们自定义异常处理器处理全局异常:

public class AHandlerExceptionResolver implements HandlerExceptionResolver {

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        if (ex instanceof RuntimeException) {
            //...
        }else if (ex instanceof BindException) {
            //...
        }else {
            //...
        }
        return new ModelAndView();
    }
}

同样可以实现异常的统一处理

05 思考

@ExceptionHandlerconfigureHandlerExceptionResolvers到底有什么关系,执行的先后顺序又是怎样的?

从源码追踪来看,所有的异常处理来自这里:

而处理@ExceptionHandler注解的异常处理器是ExceptionHandlerExceptionResolver:

ExceptionHandlerExceptionResolver的加载在初始化的时候,通过加@ControllerAdviceBean和加@ExceptionHandler的方法映射在一起。

而处理@ExceptionHandler注解的方法是ExceptionHandlerMethodResolver.

从继承关系来看,ExceptionHandlerExceptionResolver和自定义的AHandlerExceptionResolver都来自同一个接口HandlerExceptionResolver。所以说两个可以说是同一个东西。

至于先后顺序就简单了,所有的HandlerExceptionResolver都是顺序执行的,想要改变顺序可以通过list.add(index, xx)的方式。

但是自定义的异常处理器,可以控制异常是否继续向后执行,还是直接返回客户端。

06 小结

异常的处理,使用@ExceptionHandler + @ControllerAdvice已经基本满足日常的开发,简单且明了。如果想要更深层次的处理异常就需要自定义的异常处理器了。

发表评论
暂无评论

还没有评论呢,快来抢沙发~

客服

点击联系客服 点击联系客服

在线时间:09:00-18:00

关注微信公众号

关注微信公众号
客服电话

400-888-8888

客服邮箱 122325244@qq.com

手机

扫描二维码

手机访问本站

扫描二维码
搜索