一、前言
1、不规范的错误码有什么问题?
1)理解困难
描述:如果错误码的命名或描述不清晰,可能导致其他开发人员难以理解其含义。
举例:例如,一个错误码命名为“ERR1001”,没有进一步的注释或描述,可能导致其他开发人员不知道这个错误码代表的具体问题。
2)不一致性
描述: 如果错误码的命名、描述或分类不统一,可能导致代码的可读性和可维护性降低。
举例:例如,有的错误码使用三位数,有的使用两位数;有的错误码描述具体的问题,而有的描述则较为模糊。
3)排查困难
描述:如果错误码没有清晰的命名和描述,可能使得调试过程变得困难。
举例:当出现问题时,开发人员需要查看大量的日志或代码来定位问题所在。
4)冗余和重复
描述:如果错误码过多或过于复杂,可能导致代码中的错误处理逻辑变得冗余和重复。
举例:同一个错误可能在不同地方有不同的错误码,导致处理逻辑重复。
5)扩展性差
描述:如果错误码已经定义但后来需要添加新的错误码,可能需要修改多个地方的代码,增加了维护成本。
2、规范的错误码那么好,为什么不规范使用呢?
1)缺乏规范和标准:
在某些情况下,可能没有明确的规范或标准来指导如何使用错误码。这可能导致开发人员根据自己的理解和习惯来定义错误码,从而导致不规范的情况。
2)缺乏意识和经验:
某些开发人员可能没有意识到错误码规范化的重要性,或者缺乏足够的经验来正确地设计和使用错误码。
3)历史遗留问题:
在某些项目中,错误码可能已经使用了很长时间,而且已经成为了代码的一部分。在这种情况下,重新规范化错误码可能会涉及到大量的代码修改和测试,这可能会被视为成本较高。
4)个人习惯和偏好:
某些开发人员可能更倾向于按照自己的习惯和偏好来使用错误码,而不是遵循团队的规范。这可能会导致代码中的错误码使用不一致。
3、那怎么规范错误码呢
1)制定规范和标准:
团队可以制定明确的规范和标准,指导如何使用错误码,并将其纳入代码审查和开发流程中。
2)培训和指导:
为新开发人员提供培训和指导,使其了解如何正确地设计和使用错误码。
3)重构和改进:
对于历史遗留问题,可以通过逐步重构和改进的方式来规范化错误码的使用。
4)代码审查和团队协同:
通过代码审查和团队协同来确保错误码的规范化和一致性。
二、规范错误码
1、错误码-分片区
根据号段区分错误类型,这里长度定义了5位,可以根据自己系统规模调整长度
错误码 | 描述 |
---|---|
00000 | 成功 |
10000 | 参数错误 |
20000 | 业务处理失败(业务上给用户吐出) |
30000 | RPC处理失败 —>>系统_失败分类(请求0、返回1)_业务_方法_调用方CODE码(代码补齐),极端情况下吐出 99999 |
40000 | 运行处理失败:一般内部处理使用,极端情况下吐出 99999 |
99999 | 系统太火爆了,请稍后重试! –>极端情况下才吐出 |
1 | less复制代码@Getter |
2、10000-参数异常
非常简单,直接吐出即可
参数 | 说明 |
---|---|
code |
错误码 |
msg |
返回错误信息 |
1 | less复制代码 @Getter |
3、20000-业务异常
参数 | 说明 |
---|---|
code |
错误码 |
msg |
底层-错误信息 |
showMsg |
吐出-错误信息 |
1 | less复制代码@Getter |
4、30000-RPC
异常
该异常一定要合理使用,这样会让微服务直接错误信息更明确
说明:
系统_失败分类(请求0、返回1)_业务_调用方法_调用方CODE码(代码补齐)
字段 | 说明 |
---|---|
系统 | 调用系统:如用户系统User |
失败分类 | 请求失败:0;返回失败:1 |
业务 | 业务(3开头):用户信息业务:30001 |
调用方法 | 业务调用方法(指定一个数字,确保是该业务唯一的方法) |
调用方Code 码 |
后续代码中补齐,具体看异常抛出错误码使用 |
参数 | 说明 |
---|---|
code |
错误码:系统_失败分类(请求0、返回1)_业务_方法_调用方CODE码(代码补齐) |
msg |
底层-错误信息 |
1 | less复制代码@Getter |
5、40000-运行异常
1 | less复制代码@Getter |
三、错误码使用
1、10000-参数异常
构造器 | 说明 |
---|---|
ParameterException(CodeEnum.ParamsErrorEnum paramErrorEnum) |
建议使用:传入一个固定的枚举值 |
ParameterException(String message) |
不推荐:传入一个错误信息 |
1 | scala复制代码@Getter |
2、20000-业务异常
构造器 | 说明 |
---|---|
BusinessException(CodeEnum.BusinessErrorEnum businessErrorEnum) |
建议使用:传入一个固定的枚举值 |
BusinessException(String message) |
不推荐:传入一个错误信息 |
1 | scala复制代码@Getter |
3、30000-RPC
异常
构造器 | 说明 |
---|---|
RpcException(CodeEnum.RpcErrorEnum rpcErrorEnum) |
场景:处理未知的RPC 异常,如网络超时等 |
RpcException(CodeEnum.RpcErrorEnum rpcErrorEnum, String code, String showMsg) |
场景:处理已知的异常 |
RpcException(CodeEnum.RpcErrorEnum rpcErrorEnum, String code, String msg, String showMsg) |
场景:处理已知的异常 |
1 | arduino复制代码@Getter |
4、40000-运行异常
1 | scala复制代码@Getter |
四、异常吐出
1、10000-参数异常
1 | kotlin复制代码 |
2、20000-业务异常
1 | less复制代码/** |
3、30000-RPC
异常
1 | less复制代码/** |
4、40000-运行异常
1 | less复制代码 |
五、Demo
1、10000-参数异常
1 | less复制代码@ApiOperation("parameterExceptionEnum") |
1 | less复制代码@ApiOperation("parameterExceptionMsg") |
2、20000-业务异常
1 | less复制代码@ApiOperation("businessExceptionEnum") |
1 | less复制代码@ApiOperation("businessExceptionMsg") |
3、30000-RPC
异常
1 | less复制代码 @ApiOperation("rpcExceptionDefaultEnum") |
1 | less复制代码@ApiOperation("rpcExceptionEnumShowMsg") |
1 | less复制代码@ApiOperation("rpcExceptionEnumMsg") |
4、40000-运行异常
1 | less复制代码@ApiOperation("platformException") |
作者:京东保险 张宇晋
来源:京东云开发者社区 转载请注明来源
本文转载自: 掘金