Closed kevinten10 closed 3 years ago
项目的设计文档没有赶上,给大家造成一些理解的困惑。 这里我解释一下RSocket Broker中的错误码设计规范,虽然说是错误码,但是未必都是错误,有时会作为日志文件中的关键字,如将USER-100400作为登录失败提示,这样你通过grep等工具可以快速统计相关的错误,这个相信大家都明白。
所有的错误码都保存在一个Messages.properties文件中,样例代码如下:
### Listen
RST-100001 = Succeed to start RSocket Responder on {0}
RST-100500 = Error from listen server: {0}
### RSocket request
RST-200004 = RSocket REQUEST_RESPONSE: {0}
RST-200005 = RSocket REQUEST_FNF: {0}
properties文件为KV结构,value就是错误提示,可以接受外部的变量。
这里主要说明一下Key的设计。 主要包括3个部分:
RST
这样的,表示应用或者项目名称,如果你使用过JIRA,每一个项目都会有对应的简写KEY,如Hibernate就是HHH,Spring framework对应的就是SPR,这样的缩写也能让开发记住错误来自什么系统。如果有同学了解Oracle数据库的话,其中的错误码也包括特定意义的前缀,如ORA-
, NNF-
等。在RSocket Broker设计中,我有些偷懒啦,如可以定义RSB,RST等,但是考虑到RSocket还是非常简洁的,所以我就使用RST这个缩写啦。 RST-100XXX
,表示RST项目中的100组件,至于这个组件是什么,由开发者自行定义。 如RST-100表示RSocket中的监听模块。 当然这里不强求组件编码一定是数字,你用字母也可以,如RST-LOGIN500,只是如果是数字的化,最好是三位,这样方便后续数据处理。USER-100404
大家可能都明白这个就是会员系统下100子模块下的某一资源没有找到的错误。整体下来和 https://github.com/kevinten10/vrml/blob/master/vrml-error/WIKI.md 设计思想差不多,唯一的区别就是接入组件这个概念,这个也是和软件系统中的子模块对应的。
另外一些稍微说明一下:
如果有什么不够合理的地方,欢迎大家提出宝贵意见。
首先,非常感谢您的回复和解答!
我非常认同您的上述观点。 我将基于您提到的JIRA规范,对 https://github.com/kevinten10/vrml/blob/master/vrml-error/WIKI.md 进行优化和修改。
其次,我还是认为将错误码放到class
中会更加易于管理和更具有可读性,也更加贴近DDD的设计思想。
例如,我们可以为错误码提供某些其他操作,或者基于class
对错误码进行生成文档等操作。
当然,您提到的多语言是properties
方式的一种优势,这两者之前或许需要进行权衡取舍。
但我认为类似 https://github.com/kevinten10/vrml/blob/master/vrml-error/WIKI.md 提供的AbstractClass
方式,可以提供统一的基础功能实现,更有利于不同项目之间的复用和维护。
我会在 #106 中基于更新后的 vrml-error 提供新的原型实现,后面我们可以进行更多的探讨!
祝好!
@kevinten10 关于是否在class或interface定义变量,这个是可以考量的,很早的时候,估计5年前,我是使用的interface定义错误码的,后来IDE支持properties文件后,我调整啦。 另外一个原因是,一些错误码要被多语言SDK使用,如你做一个产品,有Node.js、Python、Rust等SDK客户端,这些客户端也是要用错误码的,这样SDK出现问题,消费端系统就可以看到这些错误,可以方便定位错误。 这些多语言SDK都可以使用properties文件的,而且都比较方便,如果是Java Interface,在多语言同步错误码比较麻烦。 如果一些IDE工具不支持properties文件,可以考虑维护统一的properties错误码文件,然后使用代码生成工具根据properties文件生成Java的interface,当然也可以生成其他语言的class、enum等。 这些只是提供给你参考一下。
@linux-china 再次感谢您的回复,对我而言帮助良多
您提到的多locale语言和异构编程语言是一个很好的契入点,在这方面properties具有优势。 我理解,您更多是站在一个开源产品和它所拥有的生态的角度去进行了考量, 而我对错误码的思考更多的是站在一个高内聚的业务系统内部进行考量,(工作内容所决定的) 所以interface和properties两者确实各有适用的场景。
我会继续进行相关的学习和思考。
祝好!
@kevinten10 太客气啦。 技术人员在设计时,由于大家的经历和面对的需求不太一样,所以设计才会有差别,并没有什么太大关系。
I want to discuss with you about the specification of Error Code Design
Current Error Code Design
I saw the class
RsocketErrorCode
, which is used to represent the error code in the project.Through tracking, it is found that the format starts with
RST-
.Followed by a 6-digit error code, I saw the shape:
According to my understanding, the number at the beginning should correspond to a certain category, but I did not find a detailed corresponding documentation.
Vrml's Error Code Design
Our ideas coincide. For the specification of Error Code Design, please refer to https://github.com/kevinten10/vrml/blob/master/vrml-error/WIKI.md
In the end, we should have several categories:
And through centralized management and notes, people can read and understand clearly.
At the same time, by using centralized management, we can avoid the magic numbers scattered everywhere. The concept is the same as #103 . Even generate documents automatically.
How to do it
I will provide a prototype implementaion of the Error Code Design based on the
vrml-error
module.Hope we can discuss this and have determined whether there is a better way.