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

Flutter for OpenHarmony: Flutter 三方库 husky 守卫鸿蒙项目的 Git 提交规范(前端工程化必备)

Flutter for OpenHarmony: Flutter 三方库 husky 守卫鸿蒙项目的 Git 提交规范(前端工程化必备)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在 OpenHarmony 项目的团队协作中,我们最怕遇到“带病提交”的代码。比如:某位开发者提交的代码没经过 dart format 美化、或是包含明显的 lint 警告,甚至导致整个鸿蒙工程编译失败。如果在 CI(持续集成)阶段才发现,修复成本就太高了。 husky 是从前端生态圈引进的 Git Hooks 管理神器。它能让你极简地配置 Git 的各个钩子(如 pre-commit),在代码真正提交到远端(AtomGit)之前,强制执行格式化或单元测试,确保入库的代码永远是高质量的。 一、Git Hook 工作流模型 husky 在本地提交阶段建立了一道自动化的“安检门”。 通过 失败

By Ne0inhk
基于Rust实现爬取 GitHub Trending 热门仓库

基于Rust实现爬取 GitHub Trending 热门仓库

基于Rust实现爬取 GitHub Trending 热门仓库 这个实战项目将使用 Rust 实现一个爬虫,目标是爬取 GitHub Trending 页面的热门 Rust 仓库信息(仓库名、描述、星标数、作者等),并将结果输出为 JSON 文件。本次更新基于优化后的代码,重点提升了错误处理容错性和 CSS 选择器稳定性。 技术栈 * HTTP 请求:reqwest( Rust 最流行的 HTTP 客户端,支持异步) * HTML 解析:scraper(基于 selectors 库,支持 CSS 选择器,轻量高效) * JSON 序列化:serde + serde_json( Rust 标准的序列化

By Ne0inhk
从DeepSeek-R1爆火看开源大模型推理优化:我在脉脉找到的实战方案

从DeepSeek-R1爆火看开源大模型推理优化:我在脉脉找到的实战方案

🎁个人主页:User_芊芊君子 🎉欢迎大家点赞👍评论📝收藏⭐文章 🔍系列专栏:AI 文章目录: * 【前言】 * 一、场景痛点直击:两个行业的共性困境与差异化难题 * 1. 电商智能客服场景(日均请求10万+) * 2. 金融智能咨询场景(日均请求3万+) * 二、实战突破:分场景落地优化方案(附完整代码+流程图) * 1. 核心优化架构总览(流程图) * 2. 分场景核心代码实现(新增4个关键代码片段) * (1)量化分级实现(适配金融场景精度需求) * (2)多租户隔离与共享实例实现(适配电商、金融双场景) * (3)边缘节点轻量化部署代码(适配电商峰值卸载) * (4)动态批处理与负载调度优化(核心优化代码) * 3. 优化效果对比表(分场景) * 三、脉向AI核心价值:技术人破圈的“

By Ne0inhk
最新版 GLM-5 全栈实战全教程:从本地开源部署到 API 接入(多 Agent 架构 + 全栈编程 + 就业级项目实战)

最新版 GLM-5 全栈实战全教程:从本地开源部署到 API 接入(多 Agent 架构 + 全栈编程 + 就业级项目实战)

一、背景与技术概述 随着开源大模型技术的快速迭代,GLM-5 系列凭借优秀的指令遵循能力、长上下文支持、轻量化部署适配性与商用友好的开源协议,成为企业级AI落地与个人开发者技术进阶的核心选型之一。 本文以问题驱动为核心,完整覆盖从本地开源部署到工程化API封装、多Agent架构设计、全栈项目实战的全流程,解决开发者在大模型落地过程中面临的部署门槛高、工程化能力不足、Agent架构落地难、全栈项目缺乏可复用方案等核心痛点。本文所有实操步骤均经过生产环境验证,代码可直接复用,适配就业级项目的技术要求与企业落地标准。 1.1 GLM-5 核心技术特性 * 开源协议:Apache 2.0 协议,支持商用二次开发,无额外授权门槛 * 核心能力:支持128K超长上下文窗口,原生支持函数调用、多模态理解、结构化输出,指令遵循准确率较前代提升42% * 部署适配:原生支持FP8/INT4/AWQ/GPTQ多精度量化,最低可在16G显存环境完成流畅推理,适配消费级显卡与企业级GPU集群 * 性能优化:基于稀疏注意力架构与PagedAttention机制,推理吞吐量较同参数量模型提升3倍,

By Ne0inhk