背景

我们在APP上有个功能，需要获取用户当前定位，然后当用户关闭了GPS后，没有获取到用户定位，会触发一个bug,弹窗内容如下。

问题分析

这个问题的直接原因就是移动端的值取不到，导致没有给变量赋值，就将"undefined"传给了后端，后端的这个值定义的Integer，类型转换失败，报错。

深层原因是异常处理机制有问题，于是后端和前端开始撕逼了

前端观点: 后端代码太不健壮了，就算前端传错了，也应该具备容错性;此外APP是有版本的，就算hotfix，用户也不一定升级，上一版本用户还是会有问题，所以这种问题尽量是后端来修复。

后端观点：前端没有异常兜底机制，用户不应该看到任何这种程序异常。对于有定制需求的异常，报特定异常，没有应该显示通用异常，比如弹窗"服务不可用"。另外这种属于http请求层面的约束，前端不遵从约束，还来怪我。我后端框架层面就给你拦截了，没到业务代码。

双方说的都好有道理，谁也说服不了谁。但是关于目标大家达成一致：坚决不能让用户看到这种类型的弹窗异常。

既然说服不了对方，就只能从更深入的分析问题，看看更合理的解法

通用异常的处理方式

http通常错误有

4开头：客户端参数有问题，需要后端提供debug信息。理论上应该只是联调的时候会出现，但是实际上不一定（这不就打脸了吗）
5开头：服务器端有错误，客户端有统一提供的异常处理
2开头：业务异常，如果有UI要求，后端返回一个code码，前端根据code码，展示UI。如果没有UI要求，前端直接展示后端返回的错误消息。

为了统一异常处理，一般公司的做法都是API统一返回一套数据格式，

{"error_code": "xx", // code码，1代表正常，其他表示异常。"error_msg": "xx" // msg，错误提示消息"data": "xx" // 正常数据
}

我们也是，并且将4开头的都统一处理成这套统一的数据格式。

那么前端处理异常的逻辑

这次的问题就是走到2的分支了。

前后端都没做错，问题是后端对于异常模型的抽象有问题，客户端参数有问题，需要后端提供debug信息，而不是给用户展示的错误信息。

其实服务端对于异常就分三种

客户端参数有问题的异常（前端需要debug信息和错误msg信息）
需要用户知道的业务异常，前端需要根据code展示的（前端需要code码）
通用的服务端异常，包装成消息给前端。（前端需要错误msg信息）

解法

分析清楚了问题后，就有了解法。

解法1：错误消息和debug消息分离，返回的API统一格式中增加一种字段。debug_msg 给开发看的,error_msg 还是给用户看的

解法2：定义几个枚举code。作为开发的约定

code	error_msg	参数错误含义
010000	系统错误[010000]	请求方法不支持
010001	系统错误[010001]	缺少路径参数
010002	系统错误[010002]	缺少必须的请求参数
010003	系统错误[010003]	类型不匹配
010004	系统错误[010004]	请求体异常
010005	系统错误[010005]	// 参数校验异常(body 或 param)
010006	系统错误[010006]	参数绑定异常(表单)

解法1定义比较清晰，但是为了这种corner case增加了一个字段的开销，网络传输代价高了。另外还需要前端配合更改，改动成本比较大。

解法2兼容了现在的实现，前端不用更改，但是对于客户端参数有问题这种错误提醒不是很友好，不能向前端显示具体的参数错误了。只能打日志。

和前端讨论了下，确定了解法2。

总结

所以这个问题，最后的解法

前端获取不到定位时，将undefined这个变量赋值
后端针对移动端这个服务，改动了异常处理机制

@RestControllerAdvice
public class ApiStandardException {private static final String ERROR_MSG = "系统错误";@ExceptionHandler(value = Exception.class)public ResponseEntity<Result> handle(final Exception ex, final WebRequest request)throws Exception {try {if (ex instanceof HttpRequestMethodNotSupportedException) {// 请求方法不支持LOG.warn("Request method is not supported");throw new BusinessException(WebRequestErrorEnum.METHOD_ERR.getCode(), ERROR_MSG);} else if (ex instanceof MissingPathVariableException) {LOG.warn("MISSING_PATHVAR" + ex.getMessage());// 缺少路径参数throw new BusinessException(WebRequestErrorEnum.MISSING_PARAM.getCode(), ERROR_MSG);} else if (ex instanceof MissingServletRequestParameterException) {// 缺少必须的请求参数}// 省略其他异常处理

关注【方丈的寺院】，第一时间收到文章的更新，与方丈一起开始技术修行之路

一次和前端的相互甩锅的问题记录相关推荐

项目中如何避免团队成员相互甩锅？
见过一些团队,出了问题就甩锅,问题推来推去,半天没人解决,从而影响了项目的进度,伤害了团队的士气. 一.工作职责不明确甩锅,这种情况大多是工作职责范围不明确导致的.那么我们如何确定工作职责范围呢? ...
mysql链路跟踪工具_EasySwoole利用链路追踪组件制作甩锅工具
前言最近前端老是反馈API调用异常,说请求成功但是没有数据返回! 我写的代码怎么可能有bug,肯定是前端调用的方式不对! 经过一番套鼓,直接把请求参数和响应内容打印到控制台,果然不出我所料,请求缺少 ...
北妈每日一题：如何甩锅给后端！
一之前的我一直强调,我们应该主动承担责任,这样可以使你快速成长,年轻人一定要主动而又时刻保持热情. 但后一句还有:仅限于年轻人! 如今,甩锅,绝对是你要修炼的一门技能,如果这门技能,不炉火纯青,你会 ...
测试人员花样甩锅技巧
测试人员花样甩锅技巧大全我有特殊的甩锅技巧测试人员花样甩锅技巧大全一.给研发甩锅 1.从交付质量下手 2.从研发人员下手 3.从部门衔接下手 4.从内部沟通下手二.给产品甩锅 1.从需求文档下 ...
10 年老程序员教你甩锅必杀技，论【如何优雅的甩锅】
今天是持续写作的第 45 / 100 天. 如果你有想要交流的想法.技术,欢迎在评论区留言. 以下内容为程序员绝密档案,学会之后可以在职场如履平地. 程序员常见低端甩锅招式此类招式主要是出现频率高, ...
优秀测试的花样甩锅（搞笑版）
大家都知道从事测试难免会接一些锅,这里总结一下常用甩锅技巧(仅供参考娱乐) 一.给研发甩锅 1.从交付质量下手 (1)研发交付质量刚刚太低,导致测试初期测试人员和产品测试和验收的进度很难推进下去 (2 ...
深度学习先驱 Yann LeCun 被骂到封推！AI 偏见真该甩锅数据集？
整理 | 夕颜出品 | CSDN(ID:CSDNnews) 最近,人工智能领域又发生了一次热热闹闹的争论,随后演变成一场偏离轨道的争吵,目前以 Yann 道歉封推暂告一段落...... ...
写了个牛逼的日志切面，甩锅更方便了！
点击上方蓝色"方志朋",选择"设为星标" 回复"666"获取独家整理的学习资料! 来源:juejin.im/post/68449040879 ...
甩锅！偷懒！PUA！转嫁压力！铲除异己！压榨下属！这就是职场leader真面目！...
yamy事件引发了人们对"职场Pua"的热烈讨论,一个渣leader能给员工造成巨大的心理阴影,深受毒害的网友们纷纷吐槽自己的leader.一个网友针对职场上各种leader奇葩行 ...
python跑得慢_代码跑得慢甩锅Python？手把手教你如何给代码提速30%
原标题:代码跑得慢甩锅Python?手把手教你如何给代码提速30% 来源丨Medium 编译丨王转转大数据文摘出品 https://mp.weixin.qq.com/s/bY3REj6qVw0M1N ...

一次和前端的相互甩锅的问题记录

背景

问题分析

通用异常的处理方式

解法

总结

一次和前端的相互甩锅的问题记录相关推荐

最新文章

热门文章