Spring Boot 全局异常处理策略设计(二):DispatcherServlet 与异常解析责任链源码解析

Spring Boot 全局异常处理策略设计(二):DispatcherServlet 与异常解析责任链源码解析

文章目录


Spring Boot 全局异常处理策略设计(二):DispatcherServlet 与异常解析责任链源码解析

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

在第一篇中我们已经明确了一点:
异常不是在 Controller 里被“解决”的,而是在框架层被“接管”的。

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

DispatcherServlet

无论你使用的是:

  • @ExceptionHandler
  • @ControllerAdvice
  • @ResponseStatus
  • Spring Boot 默认的 /error

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


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

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

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

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


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

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

3.1 doDispatch 的整体结构(简化)

protectedvoiddoDispatch(HttpServletRequest request,HttpServletResponse response){try{// 1. 查找 Handler// 2. 执行 Handler}catch(Exception ex){ dispatchException = ex;}catch(Throwable err){ dispatchException =newServletException(err);}processDispatchResult(request, response, handler, dispatchException);}

非常重要的一点:

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

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

catch(Throwable err){ dispatchException =newServletException(err);}

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

  • 框架不允许 Throwable 直接向外传播
  • 所有异常最终都会被“标准化”为 Exception

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


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

privatevoidprocessDispatchResult(HttpServletRequest request,HttpServletResponse response,HandlerExecutionChain mappedHandler,Exception exception){if(exception !=null){ mv =processHandlerException(request, response, handler, exception);}}

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


5. processHandlerException:责任链的起点

protectedModelAndViewprocessHandlerException(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 接口定义

publicinterfaceHandlerExceptionResolver{ModelAndViewresolveException(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 不再执行
  • DispatcherServlet 不会再抛出异常

这也是为什么:

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

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

throw ex;

结果是:

  • 异常继续向上抛
  • 对 Servlet 容器来说,这是一个未处理异常
  • 在 Spring Boot 中,通常会被 /error 接管(后续篇章重点)

10. 异常责任链流程图

throw Exception

未处理

未处理

未处理

Controller 执行

DispatcherServlet

processHandlerException

ExceptionHandlerExceptionResolver

ResponseStatusExceptionResolver

DefaultHandlerExceptionResolver

异常继续抛出

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


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

从源码可以清楚看到:

  • 没有 if-else 地狱
  • 没有硬编码异常类型
  • 完全遵循 开闭原则

你可以:

  • 插入自定义 Resolver
  • 调整顺序
  • 替换默认行为

而 DispatcherServlet 不需要修改一行代码


12. 本篇关键结论

到这一篇为止,我们已经明确:

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

但还有几个绕不开的问题

  • @ExceptionHandler 是如何被扫描并匹配异常的?
  • @ControllerAdvice 为什么能全局生效?
  • ResponseBody 是如何写入响应的?
  • Spring Boot 为什么要额外引入 /error?

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


参考资料

  • Spring Framework Reference – Exception Handling
    https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-controller/ann-exceptionhandler.html
  • DispatcherServlet 源码
    https://github.com/spring-projects/spring-framework

结束语

掘金点击访问QiunerZEEKLOG点击访问QiunerGitHub点击访问QiunerGitee点击访问Qiuner

专栏简介
📊 一图读懂系列图文并茂,轻松理解复杂概念
📝 一文读懂系列深入浅出,全面解析技术要点
🌟持续更新保持学习,不断进步
🎯 人生经验经验分享,共同成长
你好,我是Qiuner. 为帮助别人少走弯路而写博客

如果本篇文章帮到了你 不妨点个吧~ 我会很高兴的 😄 (^ ~ ^) 。想看更多 那就点个关注吧 我会尽力带来有趣的内容 😎。

代码都在Github或Gitee上,如有需要可以去上面自行下载。记得给我点星星哦😍

如果你遇到了问题,自己没法解决,可以去我掘金评论区问。ZEEKLOG评论区和私信消息看不完 掘金消息少一点.
上一篇推荐链接
Java程序员快又扎实的学习路线点击该处自动跳转查看哦
一文读懂 AI点击该处自动跳转查看哦
一文读懂 服务器点击该处自动跳转查看哦
2024年创作回顾点击该处自动跳转查看哦
一文读懂 ESLint配置点击该处自动跳转查看哦
老鸟如何追求快捷操作电脑点击该处自动跳转查看哦
未来会写什么文章?预告链接
一文读懂 XX?点击该处自动跳转查看哦
2025年终总结点击该处自动跳转查看哦
一图读懂 XX?点击该处自动跳转查看哦

Read more

不止“996”!曝硅谷AI创业圈「极限工作制」:每天16小时、凌晨3点下班、周末也在写代码

不止“996”!曝硅谷AI创业圈「极限工作制」:每天16小时、凌晨3点下班、周末也在写代码

编译 | 郑丽媛 出品 | ZEEKLOG(ID:ZEEKLOGnews) “如果你周日去旧金山的咖啡馆,会发现几乎每个人都在工作。” 这是 AI 创业公司 Mythril 联合创始人 Sanju Lokuhitige 最近最直观的感受。去年 11 月,他特地搬到旧金山,只为了更接近 AI 创业浪潮的中心。但很快,他也被卷入了这股浪潮带来的另一面——一种越来越极端的工作文化。 Lokuhitige 坦言,他现在几乎每天工作 12 小时,每周 7 天。除了每周少数几场刻意安排的社交活动(主要是为了和创业者们建立联系),其余时间几乎都在写代码、做产品。 “有时候我整整一天都在编程,”他说,“我基本没有什么工作与生活的平衡。”而这样的生活,在如今的 AI 创业圈里并不算罕见。 旧金山 AI 创业圈的真实日常 一位在旧金山一家 AI

By Ne0inhk
黄仁勋公开发文:传统软件开发模式终结,参与AI不必非得拥有计算机博士学位

黄仁勋公开发文:传统软件开发模式终结,参与AI不必非得拥有计算机博士学位

AI 究竟是什么?在 NVIDIA CEO 黄仁勋看来,它早已不只是聊天机器人或某个大模型,而是一种正在迅速成形的“新型基础设施”。 近日,黄仁勋在英伟达官网发布了一篇长文,提出一个颇具形象的比喻——AI 就像一块“五层蛋糕”。从最底层的能源,到芯片、基础设施、模型,再到最上层的应用,人工智能正在形成一整套完整的产业技术栈,并像电力和互联网一样,逐渐成为现代社会的底层能力。 这也是黄仁勋自 2016 年以来公开发表的第七篇长文。在这篇文章中,他从计算机发展史与第一性原理出发,试图解释 AI 技术栈为何会演化成如今的形态,以及为什么全球正在掀起一场规模空前的 AI 基础设施建设。 在他看来,过去几十年的软件大多是预先编写好的程序:人类设计好算法,计算机按指令执行,数据被结构化存储在数据库中,通过精确查询调用。而 AI 的出现打破了这一模式——计算机开始能够理解图像、文本和声音,并根据上下文实时生成答案、推理结果甚至新的内容。 正因为智能不再是预先写好的代码,而是实时生成的能力,支撑它运行的整个计算体系也必须被重新设计。

By Ne0inhk
猛裁1.6万人后,网站再崩6小时、一周4次重大事故!官方“紧急复盘”:跟裁员无关,也不是AI写代码的锅

猛裁1.6万人后,网站再崩6小时、一周4次重大事故!官方“紧急复盘”:跟裁员无关,也不是AI写代码的锅

整理 | 郑丽媛 出品 | ZEEKLOG(ID:ZEEKLOGnews) 过去几年里,科技公司几乎都在同一件事上加速:让 AI 参与写代码。 从自动补全、自动生成函数,到直接修改系统配置,生成式 AI 已经逐渐走进真实生产环境。但最近发生在亚马逊的一连串事故,却给整个行业泼了一盆冷水——当 AI 开始真正参与生产环境开发时,事情可能远比想象复杂。 最近,多家媒体披露,本周二亚马逊内部紧急召开了一场工程“深度复盘(deep dive)”会议,专门讨论最近频繁出现的系统故障——其中,一个被反复提及的关键词是:AI 辅助代码。 一周 4 次严重事故,亚马逊内部紧急复盘 事情的起点,是最近一段时间亚马逊系统稳定性明显下降。 负责亚马逊网站技术架构的高级副总裁 Dave Treadwell 在一封内部邮件中坦言:“各位,正如大家可能已经知道的,最近网站及相关基础设施的可用性确实不太理想。” 为此,公司决定把原本每周例行举行的技术会议

By Ne0inhk
这回真的“装”到了!来OpenClaw全国纵深行,你只需要带一台电脑……

这回真的“装”到了!来OpenClaw全国纵深行,你只需要带一台电脑……

AI Agent 的风,已经从 GitHub 吹到了线下。 过去几个月,越来越多开发者开始讨论一个问题: 当 AI 不再只是聊天,而是可以执行任务,软件会变成什么样? 在这股浪潮中,一个开源项目迅速进入开发者视野——OpenClaw,在 GitHub 上获得大量关注,相关教程、实践案例不断出现。有人用它自动整理资料,有人用它管理开发流程,还有人尝试让它执行复杂的工作流。 很多开发者第一次意识到: AI 不只是工具,它可能成为“执行者”。 不过,在技术社区之外,大多数人对 Agent 的理解仍停留在概念层面。 * AI Agent 到底是什么? * 如何在自己的电脑上运行? * 普通开发者能否真正用起来? 带着这些问题,一场围绕 OpenClaw 的开发者城市行动正在展开。 ZEEKLOG 发起的OpenClaw 全国纵深行将走进 20 个城市,用最直接的方式回答一个问题——如果

By Ne0inhk