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的错误描述中。用于核对和确认。这样就需要我们自行维护平台错误码和自己的错误码的对应关系，这是一个体力活，会很头疼，尤其如果平台有调整的时候。
• 对于第三方平台的错误码，专门开一个错误码段，例如正数为我们的错误码，负数为平台的错误码。但是如果像我们接入多个平台，有的平台错误码是正数，有的是负数就噶屁了。这样的好处是不用维护平台的错误码和我们的错误码的对应关系。不过这种方法和直接透传平台的错误码没太大区别，而且直接透传反而更简单明了。