让错误码规范起来吧
内容提要
错误码的命名和描述不清晰会导致其他开发人员难以理解其含义。命名、描述或分类不统一会降低代码的可读性和可维护性。错误码没有清晰的命名和描述会使得调试过程变得困难。错误码过多或过于复杂会导致错误处理逻辑变得冗余和重复。错误码已经定义但需要添加新的错误码会增加维护成本。没有明确的规范和标准会导致不规范的情况。团队可以制定规范和标准，并提供培训和指导。历史遗留问题可以通过重构和改进来规范错误码的使用。团队协同和代码审查可以确保错误码的规范化和一致性。
延伸解读
错误码规范化的核心：号段分类与枚举管理
文章提出用号段区分错误类型，如00000成功、10000参数错误、20000业务失败、30000 RPC失败、40000运行失败，长度可随系统规模调整。每个号段对应一个枚举类，如ParamsErrorEnum、BusinessErrorEnum，集中管理错误码和描述。这种方式让错误码含义一目了然，也便于后续扩展和维护，避免散落在代码各处。
异常构造器设计：推荐枚举，慎用字符串
文章建议异常类构造器优先接收固定的枚举值，如ParameterException(ParamsErrorEnum)，而非直接传入错误信息字符串。枚举方式能保证错误码和描述的一致性，减少随意定义；字符串方式虽然灵活，但容易导致错误码与信息不匹配，增加维护成本。对于业务异常，还额外提供showMsg字段，用于向前台展示友好提示。
RPC异常的错误码编码规则与使用场景
RPC异常错误码采用“系统_失败分类_业务_方法_调用方CODE码”的格式，如USER_0_30001_0001表示用户系统请求失败、用户信息业务、查询单个用户信息。失败分类区分请求失败(0)和返回失败(1)。构造器支持传入额外code和showMsg，用于处理已知异常，最终错误码会拼接，如USER_1_30001_0001_1000。这种设计让微服务间的错误信息更明确。
全局异常处理与统一响应格式
文章通过@ExceptionHandler分别处理参数异常、业务异常、RPC异常和平台异常，并返回统一的BaseRes结构，包含success、data、msg、code字段。对于业务异常和RPC异常，返回给前台的msg使用showMsg，避免暴露底层细节。这种统一处理减少了重复代码，也保证了不同异常返回格式的一致性，便于前端统一处理。
Q&A
错误码不规范会带来哪些具体问题？
错误码命名或描述不清晰会导致其他开发人员难以理解其含义；命名、描述或分类不统一会降低代码的可读性和可维护性；缺乏清晰命名和描述会使调试困难；错误码过多或复杂会导致错误处理逻辑冗余重复；添加新错误码会增加维护成本。
如何设计一套清晰的错误码号段？
可以根据号段区分错误类型，长度可自定义（示例为5位）。例如：00000成功，10000参数错误，20000业务处理失败，30000 RPC处理失败，40000运行处理失败，99999系统太火爆了请稍后重试。
RPC异常的错误码应该如何构造？
RPC异常错误码格式为：系统_失败分类（请求0、返回1）_业务_调用方法_调用方CODE码（代码补齐）。例如：USER_0_30001_0001表示用户系统请求失败，用户信息业务，查询单个用户信息，接口调用失败。
在代码中如何规范地抛出异常？
建议使用固定的枚举值来构造异常类，避免直接传入错误信息。例如：throw new ParameterException(CodeEnum.ParamsErrorEnum.ERROR_CODE_10002); 而不是 throw new ParameterException("参数格式异常");。
团队如何推动错误码规范化？
团队可以制定明确的规范和标准，指导如何使用错误码，并将其纳入代码审查和开发流程中；为新开发人员提供培训和指导；对于历史遗留问题，通过逐步重构和改进来规范化；通过代码审查和团队协同确保一致性和规范化。
业务异常的错误码和展示信息如何设计？
业务异常枚举包含code、msg（底层错误信息）和showMsg（吐出给用户的错误信息）。例如：ERROR_CODE_20001("20001", "订单创建失败", "您有一个订单正在创建，请稍后查看")。抛出时使用BusinessException(CodeEnum.BusinessErrorEnum.ERROR_CODE_20001)，返回给前台的msg为showMsg。
