项目运行过程中会出现各种各样的问题，常见的有以下几种情况：
业务流程分析疏漏，对业务流程的反向操作、边界分析设计不充分 调用外部服务、调用外部系统出现的超时、错误、返回值与预期不符 外部资源连通性问题，db等服务器出现的网络抖动或宕机 无论是分析设计、开发、测试、线上都需要能够准确定位问题并制定解决方案。
目的：
规范化异常的处理过程，避免异常被吞和到处都在捕获异常的情况 准确的反馈异常信息，为定位问题提供依据 通用性异常全局处理，降低业务开发关注度 对异常情况进行预警，以便能够及时响应 一、异常规划
- 业务类异常
造成业务流程不能正确执行的行为，常见的几种：
输入必填验证 业务状态约束校验 权限验证 调用外部服务返回数据不符合预期 这类异常需要给调用方返回明确的异常描述信息，一般情况下和代码无关，无需调整编码
注：是业务完整性的一部分，需提前分析
- 系统类异常
服务调用异常： 超时、中断、接口异常（非200请求） 第三方异常 ：db edis消息队列 连接失败等 注：通常与业务流程无关，与第三方系统有关，不能简单的通过调整代码解决
- 通用异常
编码不严谨、数据异常造成的问题，不可预测
举例：参数类型不匹配、空指针、数组越界
二、异常拦截
在springboot中全局异常拦截处理已知的有下面2种方案：
方案1：@ControllerAdvice、实现ErrorController
注：利用springboot自带的拦截机制，只需要定义出处理的策略，没有破坏springboot的约定
方案2：继承AbstractHandlerExceptionResolver，完全自定义处理策略
注：使用spring中最底层的类，打破了springboot的约定，能够拦截到所有异常
三、方案实践
笔者基于方案一进行实践。
- 异常拦截时序图
总结：
推荐基于springboot中@ControllerAdvice 和 ErrorController接口的约定，相对较符合springboot的约定。
其他可选方案：
继承AbstractHandlerExceptionResolver
优点：可完全自定义处理策略。缺点：对框架约定破坏较为严重，自定义处理策略容易疏漏。
继承HandlerInterceptorAdapter
理论上可以处理业务代码抛出的异常，优缺点没有进行过验证。
在这里给大家提供一个学习交流的平台，Java技术交流┟ 810309655
具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加群。
在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加群。
如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的可以加群。