SDK设计心得之错误码

错误码,是仅次于接口的游戏与SDK交流的工具。好的错误码就像接口设计一样可以大大降低接入成本,甚至不需要错误描述,仅仅通过错误码一眼就能大概确定问题原因。但是现实常常并不是这样的。这里主要是对开发中与错误码相关的一些细节的分析和探讨,包括错误码有几级,默认的错误返回怎么初始化一级对于第三方平台的错误码如何处理等。

错误码怎么定义

目前我们的接口的调用结果只有一级。因此有时候调用完一个接口以后,游戏处理的内容就会很多。有些游戏很勤快,他愿意处理各种细分的错误和异常,但是有些游戏比较懒,他其实不想去处理的,于是经常遇到有游戏有些逻辑没有处理而出现问题或者异常。

由于意识到这个问题的时候,SDK的使用量已经不小了。因此我们没法直接改为两级,这样总有一些游戏会有问题。我们目前的做法就是收归flag,把之前暴露给游戏的flag能合并的尽量合并,减少游戏的flag的数量。

推荐做法: 对外暴露的接口调用结果错误码分为两级:一级为flag,表示接口调用的结果:成功、失败、异常。一级为errorCode,表示错误原因。具体代码如下,关于一些flag的处理,我也加在代码注释里了

public abstract class CallbackRet {

	//接口调用成功,这种是获得了预期的值,走正常逻辑
	public final static int SUCC = 0;
	//接口调用失败,这种其实也是获得了预期的值,走正常的失败逻辑,如果游戏要细分因为什么失败,根据errorCode即可
	public final static int FAIL = -1;
	//接口调用异常,这种都是意外情况,一般是处理一些可以重试的逻辑。不过内部要保证重拾不要死循环
	public final static int EXCEPTION = -2;
  public int flag = FAIL;
  public int errorCode = ErrorCode.FAIL; 
	public String desc = "";
	public int platform = 0;
}


public class errorCode {
	public final static int SUCC = 0;
	public final static int FAIL = 0;
	……
}

关于错误码的默认值

我们之前回调的flag默认为成功(我也不知道当时设计的人为啥这么写,估计是手误,我就不说他脑抽了,哈哈),这就出现了一个问题,有人再失败的时候忘了设置flag,导致接口调用失败了,收到了成功的flag,然后游戏的处理逻辑就噶屁了。

因此建议:所有回调结构体或者错误码或者变量值的初始化一定是按照失败或者错误值去初始化,这样才能保证正常逻辑也错误逻辑都不会出错。

关于错误码的分段

我们这部分做的其实不是很好,虽然错误码总体没有大的问题,但是还没有做到一看错误码就知道大概什么问题,还是要对照错误码表去看。真真好的错误码,一看数字就能知道大概是什么地方的什么模块出了问题。真真做到快速方便的定位问题。这里就直接说下个人的想法。

推荐做法:

  • 错误码用五位数表示,第一位区分前后台或者内外部等、第二三位用于区分模块名称、第四五位用于区分具体的错误。之前曾经任性过,用二三位区分接口,结果发现一个模块内的很多接口,有很多的重复,造成了错误码资源的浪费和维护成本的增高
  • 每个系统都会有一些通用的错误码,因此建议把错误码最前面预留一部分出来放一些出现频率很高的通用错误码

如何处理第三方的错误码

这个问题是最头疼的问题了。例如我们接入的某个周边平台,平台没有规划号自己的错误吗,导致我们比较被动。有些错误码出现在好几个接口,但是意思竟然是完全不同的,这真(绝)是(逼)高(坑)大(死)上(人)。

目前我们的做法是直接把平台的错误码透传给游戏,这样虽然省事了,但是带来最直接的后果就是我们的错误码乱了。目前说实话还没有想到比较好的办法,这里就把想到的两种方案都列举一下吧。

推荐方案:

  • 对于调用外部平台或者第三方接口返回的错误码,做一次封装,对外提供我们的错误码,但是把平台的错误码放在callBack的错误描述中。用于核对和确认。这样就需要我们自行维护平台错误码和自己的错误码的对应关系,这是一个体力活,会很头疼,尤其如果平台有调整的时候。
  • 对于第三方平台的错误码,专门开一个错误码段,例如正数为我们的错误码,负数为平台的错误码。但是如果像我们接入多个平台,有的平台错误码是正数,有的是负数就噶屁了。这样的好处是不用维护平台的错误码和我们的错误码的对应关系。不过这种方法和直接透传平台的错误码没太大区别,而且直接透传反而更简单明了。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏斑斓

大数据流处理平台的技术选型参考

选择太多,是一件好事情,不过也容易乱花渐欲迷人眼。倘若每个平台(技术)都去动手操练一下,似乎又太耗时间。通过阅读一些文档,可以帮我们快速做一次筛选。在将选择范围...

33550
来自专栏哲学驱动设计

企业 SOA 设计(1)–ESB 设计

最近为公司完成了一个 ESB 的设计。下面简要说明一下具体的设计方案。 企业 SOA 整体方案 在前一篇《SOA、ESB、NServiceBus、云计算 总结》...

24660
来自专栏Java后端技术栈

三条路线告诉你如何掌握Spring IoC容器的核心原理

前三篇已经从历史的角度和大家一起探讨了为什么会有Spring,Spring的两个核心概念:IoC和AOP的雏形,Spring的历史变迁和如今的生态帝国。本节的主...

12230
来自专栏JAVA烂猪皮

最近刷爆朋友圈的一道面试题

最近在网上有一道面试题掀起了劲爆的浪潮,好多家公司都模仿提问了这么一道面试题,而且好多人也都在讨论这道面试题要是自己回答的话该怎么回答!这道题也是在个网站上刷爆...

12940
来自专栏大数据

Spring 数据处理框架的演变

定量分析的成败在很大程度上取决于采集,存储和处理数据的能力。若能及时地向业务决策者提供深刻并可靠的数据解读,大数据项目就会有更多机会取得成功。

65660
来自专栏程序你好

用Spring Boot颠覆Java应用开发

14320
来自专栏牛客网

美团二面面经,Java后台开发

17400
来自专栏架构师之旅

《Spring敲门砖之基础教程第一季》 第一章 概要介绍

百度百科say: Spring是一个开源框架,Spring是于2003 年兴起的一个轻量级的Java 开发框架,由Rod Johnson创建。简单来说,Spri...

21250
来自专栏JackieZheng

Spring实战——无需一行xml配置实现自动化注入

  已经想不起来上一次买技术相关的书是什么时候了,一直以来都习惯性的下载一份电子档看看。显然,如果不是基于强烈的需求或强大的动力鞭策下,大部分的书籍也都只是蜻蜓...

22560
来自专栏程序你好

如何为微服务选择REST框架

每个行业都会经历变化,变化是不可避免的。为了适应变化和交付,我们需要使用正确的工具,因此我们必须查看市场上或软件行业开源领域中现有工具的性能。性能是:对于特定数...

35920

扫码关注云+社区

领取腾讯云代金券