复杂的业务系统错误码怎么样设计比较合理呢

cc12 发布于 2018/06/12 12:29
阅读 713
收藏 2

设计复杂的业务系统,比如类似的商品管理,订单管理之类的,技术不是太复杂,但是业务比较复杂。其中涉及到大量的校验,比如说一个商品元信息的编辑,会诊对几十个字段进行参数的合法校验。不合法会进行报错。

为了方便排查报错,一般会使用错误码,抛出错误信息的同带出错误码,这个错误码怎样设计比较合理,最重要的是每抛出一个错误都要手工的去定义个添加一个错误码,这样做比较繁琐,有没有好的方式,另外错误码的格式怎样定义比较合适,怎样方便用户根据错误码找到相应的解决办法,设计过类似系统的朋友给点建议

加载中
0
maradona
maradona

除非你这个项目真的要做国际化,那就没办法,老老实实加

如果不是,那直接抛异常,错误信息由异常message承载,没必要搞什么异常码,个人觉得异常码应用场景是异常码会被使用多次或者国际化场景

0
大河向东流啊
大河向东流啊

可以给你提点建议,因为我现在做的系统就是有错误码的。

首先你需要建一个异常表,包含ID、错误码、错误信息、处理方式等,将该表里面的信息保存到Redis中,然后定义一个业务异常类,里面要包含该类的构造方法(参数为code和msg),校验失败就抛出该异常的构造方法,然后写一个统一处理异常的方法,可以包括返回值Object和该异常类,如果异常类不为空,就去Redis中查找对应的Code对应的msg,返回给前端统一的格式就OK了

0
客气了_叫我码农就好
客气了_叫我码农就好

参考http错误码设计,300,400,500代表不同的意思

0
kakai
kakai

参考HTTP的返回码,其中除了200的返回码,很多都是错误码,它也是一一例举的,根本没什么更好的办法。业务异常不宜呈现到用户面前,而一般错误码是需要直接呈现给用户看的。

把具体异常呈现给用户看,很容易让有心之人了解你的服务器代码结构,所以才额外定义了错误码。

一般呈现给用户看的,就只需要数字形式的错误码和错误描述就够了,有时错误描述都不一定需要。

0
Joyzhou
Joyzhou

错误码建议按照异常类型处理,譬如参数错误等..

返回顶部
顶部