java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > Spring Boot异常处理机制DispatcherServlet

Spring Boot全局异常处理机制中DispatcherServlet的处理流程和作用

作者：Qiuner

本文深入解析Spring Boot全局异常处理机制,重点剖析DispatcherServlet的核心作用及其异常处理流程,详细介绍了HandlerExceptionResolver接口及其三个默认实现类的执行顺序和工作原理,通过源码分析,展示了Spring MVC如何将异常转换为响应

1. 为什么一定要从 DispatcherServlet 讲起

异常不是在 Controller 里被“解决”的，而是在框架层被“接管”的。

在 Spring MVC 中，这个“接管者”只有一个入口：

DispatcherServlet

无论你使用的是：

它们最终都必须经过 DispatcherServlet 的调度与分发。

2. DispatcherServlet 在请求中的角色定位

在一次完整的请求处理中，DispatcherServlet 的职责可以概括为四步：

  1. 查找 Handler
  2. 执行 Handler
  3. 处理返回值
  4. 处理异常

异常并不是一个“补丁逻辑”，而是 DispatcherServlet 的标准流程之一。

3. doDispatch：异常真正被捕获的地方

DispatcherServlet 的核心方法是 doDispatch，异常处理的关键逻辑就在这里。

3.1 doDispatch 的整体结构（简化）

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) {
    try {
        // 1. 查找 Handler
        // 2. 执行 Handler
    } catch (Exception ex) {
        dispatchException = ex;
    } catch (Throwable err) {
        dispatchException = new ServletException(err);
    }

    processDispatchResult(request, response, handler, dispatchException);
}

非常重要的一点：

DispatcherServlet 并不会在 catch 中直接处理异常，而是统一交给 processDispatchResult。

3.2 Throwable 为什么会被单独捕获？

catch (Throwable err) {
    dispatchException = new ServletException(err);
}

这里体现了一个非常关键的设计思想：

这保证了后续异常解析链的统一性。

4. processDispatchResult：异常处理的真正入口

private void processDispatchResult(
        HttpServletRequest request,
        HttpServletResponse response,
        HandlerExecutionChain mappedHandler,
        Exception exception) {

    if (exception != null) {
        mv = processHandlerException(request, response, handler, exception);
    }
}

只要 exception != null，就会进入异常处理流程。

5. processHandlerException：责任链的起点

protected ModelAndView processHandlerException(
        HttpServletRequest request,
        HttpServletResponse response,
        Object handler,
        Exception ex) {

    for (HandlerExceptionResolver resolver : this.handlerExceptionResolvers) {
        ModelAndView mv = resolver.resolveException(request, response, handler, ex);
        if (mv != null) {
            return mv;
        }
    }
    throw ex;
}

这一段代码，是 Spring MVC 异常机制的灵魂。

从中可以明确看出三点：

  1. 异常处理是一个 Resolver 链
  2. 按顺序逐个尝试解析
  3. 谁先返回非 null，谁就“吃掉”异常

6. HandlerExceptionResolver 责任链模型

6.1 接口定义

public interface HandlerExceptionResolver {
    ModelAndView resolveException(
        HttpServletRequest request,
        HttpServletResponse response,
        Object handler,
        Exception ex);
}

设计目的非常明确：

给异常一个“翻译成响应”的机会

6.2 默认的三个异常解析器

Spring MVC 默认注册了三个 Resolver：

Resolver作用
ExceptionHandlerExceptionResolver处理 @ExceptionHandler
ResponseStatusExceptionResolver处理 @ResponseStatus
DefaultHandlerExceptionResolver处理 Spring 内置异常

它们构成了一条有顺序、有分工、有兜底的异常责任链。

7. Resolver 链的执行顺序是如何确定的

Resolver 并不是写死的，而是通过初始化流程注入：

this.handlerExceptionResolvers = getDefaultStrategies(context, HandlerExceptionResolver.class);

最终顺序为：

  1. ExceptionHandlerExceptionResolver
  2. ResponseStatusExceptionResolver
  3. DefaultHandlerExceptionResolver

顺序的设计逻辑是：

8. 异常是如何被“吃掉”的？

当某个 Resolver 返回了非 null 的 ModelAndView：

if (mv != null) {
    return mv;
}

意味着：

这也是为什么：

一个异常只会被一个 Resolver 处理

9. 如果所有 Resolver 都不处理会怎样？

throw ex;

结果是：

10. 异常责任链流程图

图1 Spring MVC 异常解析责任链流程图

11. 为什么说这是一个“非常优雅的设计”

从源码可以清楚看到：

你可以：

而 DispatcherServlet 不需要修改一行代码。

12. 本篇关键结论

到这一篇为止，我们已经明确：

  1. DispatcherServlet 是异常处理的唯一入口
  2. 异常处理不是一个方法，而是一条责任链
  3. @ExceptionHandler 只是其中一个 Resolver
  4. Spring MVC 把“异常 → 响应”的逻辑彻底解耦

但还有几个绕不开的问题：

👉 这些问题，必须进入 Resolver 内部才能解释清楚。

到此这篇关于Spring Boot全局异常处理机制中DispatcherServlet的处理流程和作用的文章就介绍到这了,更多相关Spring Boot异常处理机制DispatcherServlet内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

参考资料

您可能感兴趣的文章:
阅读全文