Go 语言项目开发实战
孔令飞
腾讯云专家工程师,前 Red Hat、联想云工程师
41030 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 61 讲
Go 语言项目开发实战
15
15
1.0x
00:00/00:00
登录|注册

18 | 错误处理(上):如何设计一套科学的错误码?

纯数字表示,不同部位代表不同的服务,不同的模块
reference字段包含解决错误的文档链接地址
message表示错误的具体信息
code字段表示调用API接口失败
100001开始,1000以下为github.com/marmotedu/errors保留code
500 - 服务端出问题
400 - 客户端出问题
200 - 请求成功执行
纯数字表示,不同部位代表不同的服务,不同的模块
在Body中返回详尽的错误信息
返回http 404 Not Found错误码
在Body中返回简单的错误信息
返回http 404 Not Found错误码
HTTP Body中包含错误信息
返回200 http status code
思考下你还遇到过哪些更科学的错误码设计
有没有一种Low Code的方式,根据错误码规范,自动生成错误码文档呢?
Code码设计规范
错误码对外暴露两种错误信息
错误码包含HTTP Code和业务Code
对外暴露的API接口需要有一套规范的、科学的错误码
IAM API接口返回值说明
Code设计规范
HTTP Status Code
业务Code码设计
第三种方式
第二种方式
第一种方式
对外对内分别展示不同的错误信息
业务Code码标识
课后练习
总结
IAM项目错误码设计规范
错误码设计建议
常见的错误码设计方式
期望错误码实现的功能
参考文章

该思维导图由 AI 生成,仅供参考

你好,我是孔令飞。今天我们来聊聊如何设计业务的错误码。
现代的软件架构,很多都是对外暴露 RESTful API 接口,内部系统通信采用 RPC 协议。因为 RESTful API 接口有一些天生的优势,比如规范、调试友好、易懂,所以通常作为直接面向用户的通信规范。
既然是直接面向用户,那么首先就要求消息返回格式是规范的;其次,如果接口报错,还要能给用户提供一些有用的报错信息,通常需要包含 Code 码(用来唯一定位一次错误)和 Message(用来展示出错的信息)。这就需要我们设计一套规范的、科学的错误码。
这一讲,我就来详细介绍下,如何设计一套规范的、科学的错误码。下一讲,我还会介绍如何提供一个 errors 包来支持我们设计的错误码。

期望错误码实现的功能

要想设计一套错误码,首先就得弄清我们的需求。
RESTful API 是基于 HTTP 协议的一系列 API 开发规范,HTTP 请求结束后,无论 API 请求成功或失败,都需要让客户端感知到,以便客户端决定下一步该如何处理。
为了让用户拥有最好的体验,需要有一个比较好的错误码实现方式。这里我介绍下在设计错误码时,期望能够实现的功能。
第一个功能是有业务 Code 码标识。
因为 HTTP Code 码有限,并且都是跟 HTTP Transport 层相关的 Code 码,所以我们希望能有自己的错误 Code 码。一方面,可以根据需要自行扩展,另一方面也能够精准地定位到具体是哪个错误。同时,因为 Code 码通常是对计算机友好的 10 进制整数,基于 Code 码,计算机也可以很方便地进行一些分支处理。当然了,业务码也要有一定规则,可以通过业务码迅速定位出是哪类错误。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

错误码设计是软件开发中非常重要的一环。本文详细介绍了如何设计一套科学的错误码,包括功能需求、常见设计方式和优秀设计思路。作者首先强调了错误码应实现的功能,包括业务Code码标识和对外对内展示不同的错误信息。然后,作者列举了三种常见的错误码设计方式,并分析了它们的优缺点。最后,提出了一套优秀的错误码设计思路,包括业务Code码设计和请求出错时如何设置`http status code`。此外,还介绍了业务Code码设计的规范,建议采用纯数字表示,不同部位代表不同的服务和模块,以及如何通过错误码快速定位问题和定位代码行。文章还介绍了IAM项目的错误码设计规范和API接口返回值说明。总的来说,本文对错误码设计提出了系统性的思考和建议,对于需要设计错误码的技术人员具有一定的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Go 语言项目开发实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(24)

  • 最新
  • 精选
  • timidsmile
    对于使用 httpCode 表示业务逻辑的情况(针对 错误码设计方式的第二种和第三种),统一监控如何区分是自身服务问题还是业务问题呢? 比如,对于 500 类错误,如何区分是自身服务panic等导致的,还是上游请求数据有问题(yaml data couldnt be encde 等)造成的呢? 会不会让监控变得复杂?

    作者回复: 你们的监控如果一定要区分这两种情况,那只能从业务code上区分了。 如果感觉从业务code区分比较麻烦,那可以将yaml data couldnt be encode这种错误,再映射为一个HTTP Status Code,比如:512。 这种复杂度,是不可避免的,因为监控是一定要感知到差异的,这些差异要么来自于业务code,要么来自于http status code

    2021-07-08
    3
    4
  • Allen
    新浪微博API应该是国内互联网应用最早最广的API,确实很有参考价值。

    作者回复: 新浪微博的缓存系统设计的也是很NX

    2021-11-24
    3
  • 咖梵冰雨
    var _ errors.Coder = &ErrCode{} 请问这一段代码有什么作用

    作者回复: 确保ErrCode实现了errors.Coder 接口,如果没实现,在编译期间就能发现错误。

    2021-11-11
    3
  • 静心
    关于错误码,我觉得最好尽量使用HTTP状态码进行判断。因为毕竟老师也说了,避免解析Body。在rfc7231规范中占用了600以下的状态码,在这些状态码中512~599尚未被注册使用,有一定的保留空间。所以600以上的就可以用于自定义的状态码。

    作者回复: 感觉不太适合,原因如下: 1. HTTP的状态码和业务的状态码其实不是一回事情,强行放一起,会有点乱。 2. 如果使用HTTP状态码,就意味着,错误码是有限的,而且还比较少。不利于系统的演进,因为随着系统规模的扩大,错误码很容易突破HTTP闲置状态码的个数。 3. HTTP状态码不能包含更多的信息

    2021-10-19
    2
  • 宙斯
    三种设计方式有两种返回http 404 Not Found,是写错了吗?

    编辑回复: 收到反馈,我们和老师确认下 老师的回复:“没写错哈。虽然后面2个HTTP status code返回的是一样,但是response body中返回的错误信息丰富度是不一样的。”

    2021-07-06
    2
    2
  • 李凯
    这套错误码如何根据header lang参数,进行中英文切换

    作者回复: 这个还没有实现,你可以网上搜下实现方法,并尝试实现。带着问题去学习,这种学习效果更好

    2022-11-06归属地:广东
    1
  • Sam Fu
    问题1:可以维护一套错误码管理系统。用户在后台手动创建维护,然后系统在启动时加载系统所有的错误码。业务在处理完客户端响应时,由中间件统一实现返回response reference字段,如果业务方显式指定reference字段,则中间件不再覆盖。 问题2:整个业务组只维护一套错误码管理后台。错误码具有如下三个属性: - code - message - 是否是预期之内。 优点如下 - 统一错误码使用,如请求参数错误对应错误码为200010。因为如果不统一的话,不同团队对「请求参数错误」的错误码就不一样了。整体的使用会很乱。 - 错误码本身有个字段标识是否预期之内,这样可以单独对这个字段加监控报警,减少运维压力。

    作者回复: 666

    2022-10-27归属地:广东
    1
  • CQS
    孔老师你好,我在github 仓库上看到你留有微信我添加并没有通过。麻烦能不能通过一下或者拉我进群一起学习?

    作者回复: 加了哈,已入群

    2021-07-07
    3
    1
  • helloworld
    有一个疑问:公司的技术架构如果采用微服务的话,可能有上百个服务,错误码的服务部分只预留两位数,是否会不够用,还是说将微服务分成服务类,以减少服务数量呢

    作者回复: 如果真的需要很多服务,那错误码可以再多一位。 规范是人定的,具体需要看是否匹配业务,规范如果不匹配业务,需要修改之前的规范,并形成新的规范,都是可以的。

    2021-07-07
    1
  • 流星泪
    对内和对外的错误信息,对内可以有敏感信息,对外展示给用户的是安全信息 怎么设计接口返回message,对内对外是不一样的呢? 日常开发中,我们不都是通过日志记录敏感错误信息 去定位问题吗

    作者回复: 对内对外是可以不一样的。返回的错误中也可能有敏感信息

    2022-06-09归属地:广东
收起评论
显示
设置
留言
24
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部