【游戏开发】004》业务错误码设计

实际开发当中，开发容易遇到哪些问题

• 设计稿中提示语言经常改动
• 大部分小公司没有完整的设计稿
• 大部分开发者英文水平欠佳，变量命名很糟糕，导致拖累开发进度
• 不必要的错误码设计。如：非管理员行使管理员权限，此等为非法操作，不应该单独增加错误提示

我们为什么需要错误码

• 错误码主要是为了业务需要而设计的

错误码面向哪些群体

• 用户，用户需要知道具体的错误信息。如：提示登录密码错误
• 前端开发者，开发者需要知道具体的业务错误信息。如：非管理员做管理员操作
• 后端开发者，开发者需要知道具体的业务错误信息，给前端开发者提示

用户对错误码的要求

• 不关心错误码代号
• 反馈信息要准确、言辞要委婉
• 支持多语言（可选项）
• 不同业务操作时，同一错误码提示不同（可选项）
• 结论：
  • 后端返回错误码及通用提示信息给前端排查问题，具体提示给用户的信息应由前端开发定义。

开发者对错误码的要求

• 需要根据错误码执行指定操作
• 需要明确的错误提示
• 当某个业务操作失败时，能够迅速定位到业务异常处，并给出合理解释。（非代码异常）

我的错误码设计

重点说明

• 一个正常的客户端应该对某一些操作请求加以限制，当这些操作不满足条件却被发起时，统一返回非法操作错误码，为配合前端开发，将会在开发阶段返回提示具体的错误信息。而不是为每个错误信息编码，以减轻工作量和维护成本。以下示例：
  • 非管理员身份发起管理员权限操作
  • 非好友关系发起解除好友关系操作
  • 发起指定请求缺少参数，参数类型错误
  • 请求非法不支持
  • 无权限访问
• 服务端不应该过度验证。以下示例：
  • 用户设置密码，输入两次新密码，应由前端校验是否一样
  • 用户使用旧密码设置新密码，新旧密码一致，应由前端校验是否一样

返回结构

{
    "data": {},  # 数据段
    "code": "0",  # 错误码
    "msg": "成功" # 提示（面向前端开发者，上线可关闭，节约流量）
}

错误码设计（缓更）

OPERATION_SUCCESS   0   成功
OPERATION_INVALID   1000    操作非法
OPERATION_FREQUENT  1001    操作频繁
    
ERROR_UNKNOWN   1100    未知错误
ERROR_SERVER    1101    服务器异常
ERROR_SERVER_OTHER  1102    第三方服务器异常

AUTH_EXPIRE  2000  身份认证信息已失效