希望大家可以收获：
1，背景分析是否贴合工作的实际场景，能否触及痛点；
2，统一的技术方案，并演示最终的实现效果；
3，前端和后端相对完整的技术实现方案，系统的思考方式；
背景和需求
不同人群对错误处理的期望不同：这里基于业务系统简单列表汇总；
| 人群 | 错误提示的期望 |
|---|---|
| 业务系统产品经理 | 错误提示也是产品设计的一部分，标识正常业务的边界，基于错误提示可以快速的进行业务功能的边界条件，关键流程流向提示； |
| 业务系统测试人员 | 能定提示到是到底是前端还是后端的问题，快速的分类bug，指派给对应的开发人员;进行需求的二次确认，一些参数边界的提示信息必须符合产品规约。 |
| 业务系统前端开发人员 | 联调的时候，后端的错误可以提示哪里出错了，如果是参数错误，让我指引我哪个参数错了，我好调整如果是后端逻辑或者内部错误，方便我提供截图和traceId给到后端开发，让后端去解决； |
| 业务系统运维人员 | 后端资源耗尽了，最好可以提示我哪块资源不足，如何补充；中间件有问题了，告知我哪个中间件，建议的运维方法；如果实在无法在界面上告诉我，可以快速看到对应的应用日志，丢回给开发去进一步定位问题。 |
| 业务系统后端开发人员 | 开发和集成测试环境，最好在界面上或者控制台能看到堆栈信息，哪行代码出错了；最次也要能从界面或者控制台，或者抓包中找到traceId，方便我从日志中或者调用链跟踪系统中快速的定位问题，方便快速解决问题； |
| 业务系统管理层 | 可服务性好，站在用户的角度，希望有规范的提示和回到正确流程的提示；站在客户方的二开或者集成工程师角度，希望错误码能统一，并且对提示，方便我快速集成和二开；站在开发周期来说，希望错误提示可以加快前后端联调，测试的工作效率； |
| 架构师 | 错误处理公共组件化，兼顾开发期的可扩展性，复用性，易用性，以及兼顾运行期的可服务性； |
| 二开用户（业务系统B端-开发人员） | 我要错误编码，还要指导提示，最好在本接口中返回给我，或者指引我一个文档，我按照编码去查；能加速我快速的集成或者二开； |
| 用户：业务系统B-C端用户 | 告诉我哪里出错了，正确的使用方法，让我可以回到正确的流程；最好还能显示级别；提示不能为空，不能有英文，不能有堆栈信息，不能有我看不懂的信息 |
| 客户：业务系统B端应用配置人员 | 同C端用户，主要是告诉我哪里操作错了，让我可以回到正确的流程中； |
下面进行抽象和汇总。
一个合适的错误处理方案应该是怎样的/p>
这里做一下调整，统一把分散在微服务里面错误码枚举放到团队公共的SDK中；
后端错误的分类：
内部：主要是对前端，大部分错误通过异常的方式抛出，后端做统一的处理；
外部系统：主要对接外部系统，有些是直接拼接错误码和错误消息的方式输出的；
建立在服务可用，即httpStatus=200的基础上，内部异常的分类：
| 错误描述 | 说明 |
|---|---|
| 输入参数非法 | 参数缺失，参数不符合规则要求，请求类型不支持 |
| 逻辑错误 | 不具备操作权限，jvm内部的异常，比如NPE等，方法超时，运行时异常（空指针等） |
| 内部环境错误 | 依赖的中间件不可用或者调用方法 错，比如SQL写错了了 |
如果 关服务不可用： nginx需要有对应的40X , 友好json数据
如果 关后面的后端服务不可用： 后端服务需要返回 40X，50X的友好json数据；
| 用户 | nginx 故障 | 后端 关 | 后端服务 |
|---|---|---|---|
| 前端资源 | 404友好提示页面 | 不经过 | 不经过 |
| 前端访问后端资源 | url错误，浏览器默认404页面 | 路由找不到，404转换为json数据 | 40x转换为json数据 50x自然转换成了json数据 |
查看老业务系统的代码，现在后端的错误处理方式分两种：
| 错误处理方式 | 说明 | 目前的缺点 |
|---|---|---|
| 统一异常处理 | 通过在web-api-service工程中 通过@RestControllerAdvice 标注一个统一的异常处理类 对每一种类别的异常进行处理统计如下表 | 异常的层级和分类不够清晰有些异常 e.getmessage可能是英语，看不懂； |
| 直接拼装错误码和错误消息 | 分散在业务代码中，见下面的截图和部分代码截取 | 无法统一管理错误码和错误信息，并且错误信息中无正确操作指引信息 |
老业务系统统一异常处理分类
| 异常分类 | 父类 | 错误码 | 说明 |
|---|---|---|---|
| RuntimeException | Exception | SERVER_ERROR(50000L, “服务异常”) | 运行时异常 |
| MissingServletRequestParameterException | ServletRequestBindingException-》NestedServletException-》ServletException-》Exception | ILLEGAL_PARAMETER_ERR(10005L, “非法的参数”)缺少必传参数+paramName | 接口参数绑定异常 |
| HttpMessageNotReadableException | HttpMessageConversionException-》NestedRuntimeException-》RuntimeException-》Exception | CLASS_CAST_ERR(10009L, “类型转换异常”), | JSON转换异常，包含更多的消息转换异常 |
| HttpRequestMethodNotSupportedException | ServletException-》Exception | METHOD_NOT_SUPPORT(40007L, “请求方法不正确”), | ajax的http方法写错，或者签名不对，如媒体类型等； |
| ServiceException | |||
| RuntimeException->Exception | 引擎层自定义的code,msg,异常数据 | 在引擎层进行了编码和MSG的规范 | |
| BusinessRuleException | RuntimeException->Exception | 引擎层自定义的code,msg,异常数据2 | 在引擎层进行了编码和MSG的规范 |
| PortalException | RuntimeException->Exception | Web Api异常 Portal 抛出的自定义异常 code msg 异常数据自定义 | webAPI异常范围太广泛 code msg 的定义不太规范，有随意定义的代码出现 |
| RemotingException | Exception | 调用远程服务失败 REMOTING_ERR(10006L, “调用远程服务失败”) | webAPI调用引擎的dubbo服务异常 |
| RpcException | RuntimeException->Exception | 调用远程服务失败 REMOTING_ERR(10006L, “调用远程服务失败”) | dubbo框架异常 |
| UndeclaredThrowableException | RuntimeException->Exception | 一般用在在调用代理的方法调用的时候抛出的检查异常__/em> 分别匹配_LicenseException ServiceException RuntimeException 如果类型匹配不上，code,msg __SERVER_ERROR(50000L, “服务异常”), | 未定义异常 未定义抛出异常 这里做了一个统一处理，理论上是不起作用的，会提前分流到对应的异常类型中去 |
| InvocationTargetException | ReflectiveOperationException-》Exception | 用在调用代理的方法或者构造函数的时候抛出的检查型异常/strong>SERVER_ERROR(50000L, “服务异常”), | 进入托底异常 |
| LicenseException | ServiceException-》RuntimeException->Exception | 校验许可证抛出的异常code msg 异常数据自定义 | 许可证异常，引擎层的自定义异常 |
| ConstraintViolationException | ValidationException->RuntimeException-》Exception | ILLEGAL_PARAMETER_ERR(10005L, “非法的参数”), | 参数校验异常 |
| MethodArgumentNotValidException | MethodArgumentNotValidException->Exception | ||
| MaxUploadSizeExceededException | MultipartException-》NestedRuntimeException-》RuntimeException-》Exception | OSS_UPLOAD_SIZE_LIMIT_EXCEEDED(10025L,“文件上传超出大小限制”) | oss上传文件超出大小限制异常 |
直接拼接错误码返回
Exception: 可以预见到的异常情况，应该被捕获或者处理，在java中，分为检查异常（编译期）和不检查异常（运行期）。
Error: 出现了错误系统不能正常运行或者恢复，一般情况不容易发生；
共同点：都继承自Throwable，在java中只有Throwable的子类可以被catch或者throw;
ERROR一般是后端服务挂了，一般无法恢复，提示501 服务不可用或者404 ；
Throwable 异常的基类，一般不直接处理；
重点处理的Exception和RuntimeException
| 异常分类 | 说明 |
|---|---|
| CheckedException 检查型异常， | 一般直接继承Exception,(RuntimeException除外)，需要显示的try-catch 否则编译 错 |
| RuntimeException 运行时异常 | 程序运行过程中发生的异常，编译器无法提前发现，一般的业务异常都是运行时异常； |
在处理异常的时候，有4个基本规则需要注意：
- 不要catch 最普遍的Exception ，而应该优先捕获具体的异常，可以留下足够的诊断信息；
- 不要生吞异常，应该尝试抛出或者写到日志，否则无法判断异常发生的位置；
- 不要使用e.printStackTrace(),在分布式系统中，无法确定输出到了什么位置，应该输出到日志中；
- 提早抛出，晚点捕获；提高效率
自定义异常的时候需要注意两点： 1，尽量不要定义检查异常 2，异常需要保留足够的诊断信息，但是也需要脱敏；
新业务系统错误码统一管理
- 按照微服务统一的规范枚举统一管理错误码，错误信息，并填充建议操作信息，可通过共同接口进行规范；
比如design微服务定义微服务级别的错误码枚举 需要实现 ErrorCodeI接口，填充服务名称，错误码，错误提示信息，正确操作指引信息；
- 收缩自定义的errcode,errmessage到对应的枚举中，进行统一的编码和错误信息配置；
- 关提供接口和前端页面，展示所有的错误码和错误信息，建议处理方法； 作为一个补充的查找建议操作的方案；（可在 关汇聚所有的微服务中的错误码信息，并展示出来）
新业务系统异常体系分级分类
1,输入参数异常（提示给到前端）
2,逻辑业务异常，JVM运行时异常（各微服务按照类别自行扩展）
3,内部异常（中间件的连接错误和异常，进行统一封装）
4, 托底的异常捕获（如果不是以上的异常，直接提示服务器内部错误，并提供可以查错的地方；）
分别配置好对应的errcode, errmsg需要考虑到英文的情况，可对已经发现的中间件异常进行定义前置名称，英文异常信息通过翻译接口解决，最差要做托底中文信息替换；
前端
*原则： 服务端能响应的、能返回错误的，提示语使用后端返回 服务端不能响应的、不能返回错误的，提示语使用前端约定 *1. 状态码一览表
| Http Status | Code | Error Code | 等级 | 提示语 | 备注 |
|---|---|---|---|---|---|
| 200 | 200 | B | |||
| 201 | B | ||||
| 300 | 300 | – | – | – | 通常不需要提示 |
| … | – | – | – | 同上 | |
| 400 | 400 | B | |||
| B | |||||
| B | |||||
| B | |||||
| B | |||||
| B | |||||
| B | |||||
| B | |||||
| B | |||||
| B | |||||
| B | |||||
| B | |||||
| 401 | B | 权限相关，提示登陆或无权限 | |||
| 402 | |||||
| 403 | F/B | ||||
| 404 | F | NOT FOUND | |||
| … | |||||
| 500 | 500 | F | 服务端异常 | ||
| 501 | F | ||||
| 502 | F |
/strong>
- 后端返回数据格式
字段 说明 errCode 错误码 errMessage 提示消息 data 返回结果 traceId skywalking的跟踪ID
- 前端实现axios拦截器异常捕获，封装组件实现，展示逻辑&形式
更多的需求点
| 岗位角度 | 需求补充 |
|---|---|
| 后端 | 1，提供一个统一操作异常的工具类，替代throw new Exception(),规范异常的抛出 2，错误码的规则：8位 1-2服务 3-4异常分类 5-8 序 ，防止多微服错误码重叠 3，错误提示信息和正确引导分成两个字段返回到前端； |
| 前端 | 1，提示的风格具体应该是什么样的，可能是UED来定义，但是我们的框架要支持灵活的去扩展实现这种信息提示的展示， 2，再提供一套风格的UI,手动关闭toast提示；3，前端出错了的错误堆栈或者位置信息应该有地方可查； |
| 测试 | |
| 管理 | 1，后期可考虑加入客户主动反馈错误功能，通过业务人员间接传递特别影响技术团队的口碑；（福春） |
| 运维实施 | 1，错误码的提示可以直接链接到统一的错误码说明页面，加快实施人员的效率；2. 如果提示不够，通过traceID能到对应的分布式日志系统查到调用链的信息； |
日常开发中如何使用
错误码： 如果是系统内部的，即不对外部的第三方系统开发，错误码使用字符串，可读性更好；
如果是对外部的第三方系统的，可使用统一的数字编码，也可使用字符串，根据需要来；
加入你负责一个服务的开发，下面两种场景是你必须要考虑的。
团队公用SDK中定义微服务对应的错误枚举
写法如下：在client包中；
已有的错误处理融合
如果已经有自己的错误处理了，跟统一异常处理进行融合，融合方式具体情况具体分析。提供统一的扩展方式。
可单独找 @李福春(lifuchun) 一起看整改方式 。
工程分工和任务跟进
完成标志：在测试环境中提示规范，有价值。
明确指出是哪个服务的什么问题，建议提示一定要准确到位。 测试做验证。
小结
作为一名程序员，需要站在更高的角度，用产品思维，系统思维，终局思维，商业运营思维去看待出现的痛点问题。
通过从前到后的约定错误和异常提示，解决各个岗位对软件系统排错性的建设。
下期我直接输出一个统一的java异常处理的后端SDK样例。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！