前言
在程序中我们经常通过异常的方式表示错误，然而对于 RPC 或者 REST 接口来说，抛出异常并不合适，这时候我们经常使用错误码来表示错误。常见的错误码有数字错误码，还有英文错误码。由于英文错误码更具有表达性，因此项目选择了英文错误码。而且英文错误码拥有几乎无限的扩展能力，适合细分错误情况。
错误码规范
错误码格式参考了阿里错误码的几个文档。 阿里云错误码中心
如何使用
在我的理解里，每个服务使用的错误码应该足够调用方去识别错误的类型，如参数冲突，服务器异常等，这些情况服务的提供方应该告知调用方。但是参数错误的情况是调用方的责任，服务提供方只需要编写详细的参数文档，在识别到参数错误时直接返回统一的错误码即可。
多个服务嵌套使用时，如A服务调用B服务，A服务不应该在B服务调用不成功时直接返回B的错误信息，而是应该自行封装错误信息，因为B服务的错误信息可能会改变，这时候可能会返回意料之外的信息。且A服务可能需要对B服务的错误信息进行转换，因此不应该简单返回B服务的错误信息。
对于错误情况，没必要列出能够识别的该请求的所有错误，在遇到第一个错误时，就应该及时返回。
错误码信息应该在服务的接口代码中详细写出，或者写成文档，这样服务的使用者才知道如何处理这些错误。
示例
这里是一个手机号码注册的 RPC 服务方法，会返回3个错误码。在参数校验出错时，直接返回 InvalidParameter；手机号码冲突时，需要返回 OperationConflict 提示调用方；验证码错误的情况也需要返回 InvalidParameter.AuthCode.Incorrect 进行提示。
/**
* 通过短信验证码注册账号
* 该方式会随机生成用户名
* 若密码为 null 会随机生成密码
* 推荐使用该方式进行注册，且密码不允许为 null
*
* @errorCode InvalidParameter: 手机号码或验证码或密码格式错误
* OperationConflict: 手机号码已经存在
* InvalidParameter.AuthCode.Incorrect: 短信验证码错误
*
* @param phone 手机号码
* @param authCode 短信验证码
* @param password 密码
* @return 新创建的用户
*/
default Result<UserDTO> signUpBySmsAuthCode(@NotBlank @Phone String phone,
@NotBlank @AuthCode String authCode,
@Password String password) {
throw new UnsupportedOperationException();
}
