复杂的业务系统错误码怎么样设计比较合理呢
设计复杂的业务系统，比如类似的商品管理，订单管理之类的，技术不是太复杂，但是业务比较复杂。其中涉及到大量的校验，比如说一个商品元信息的编辑，会诊对几十个字段进行参数的合法校验。不合法会进行报错。
为了方便排查报错，一般会使用错误码,抛出错误信息的同带出错误码，这个错误码怎样设计比较合理，最重要的是每抛出一个错误都要手工的去定义个添加一个错误码，这样做比较繁琐，有没有好的方式，另外错误码的格式怎样定义比较合适，怎样方便用户根据错误码找到相应的解决办法，设计过类似系统的朋友给点建议
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
错误码建议按照异常类型处理，譬如参数错误等..
参考HTTP的返回码，其中除了200的返回码，很多都是错误码，它也是一一例举的，根本没什么更好的办法。业务异常不宜呈现到用户面前，而一般错误码是需要直接呈现给用户看的。
把具体异常呈现给用户看，很容易让有心之人了解你的服务器代码结构，所以才额外定义了错误码。
一般呈现给用户看的，就只需要数字形式的错误码和错误描述就够了，有时错误描述都不一定需要。
参考http错误码设计，300，400,500代表不同的意思
可以给你提点建议，因为我现在做的系统就是有错误码的。
首先你需要建一个异常表，包含ID、错误码、错误信息、处理方式等，将该表里面的信息保存到Redis中，然后定义一个业务异常类，里面要包含该类的构造方法（参数为code和msg）,校验失败就抛出该异常的构造方法，然后写一个统一处理异常的方法，可以包括返回值Object和该异常类，如果异常类不为空，就去Redis中查找对应的Code对应的msg，返回给前端统一的格式就OK了
除非你这个项目真的要做国际化,那就没办法,老老实实加
如果不是,那直接抛异常,错误信息由异常message承载,没必要搞什么异常码,个人觉得异常码应用场景是异常码会被使用多次或者国际化场景