背景:
我们提供一个 SDK ,有很多 API 供上层应用使用。每次 API 变更都要考虑前向兼容,不能影响已有应用(否则代价巨大)
问题:
假设我有一个 API ,设为 DoA ,当 DoA 出现异常的时候,会通过另一个回调函数 OnError(err)返回错误信息给上层应用。
假设前期的错误码回调设计是这样的( err 是个结构体,包含 code 和字符串):
{1001, "原因 1"},
{1002, "原因 2"},
{1003, "原因 3"}
最近有部分用户提出来,部分错误码设计不合理:原因 2 太粗,需要细化为原因 2a ,2b ,2c 。需求是合理的。
那这个时候整个 OnError 的错误码回调应该如何设计呢?(即能精细化错误码,又要保证前向兼容)
当前想到的几个方案:
方案 1:
直接新增 code 和错误码字符串,
{1001, "原因 1"},
{1002, "原因 2"},
{1003, "原因 3"},
{10021, "原因 2a"},
{10022, "原因 2b"},
{10023, "原因 2c"},
问题:会导致原来只判断 1002 的应用不兼容
方案 2:
新增 code 和错误码字符串,当出现 2a 导致的错误时,回调两次,把 1002 和 10021 都回调一下
问题:上层应用不一定能接收两次回调,或者可能导致上层应用出现一些时序相关的奇怪问题
方案 3:
不新增 code ,通过不同的字符串来标识精细化的错误信息。类似这样:
{1001, "原因 1"},
{1002, "原因 2a"},
{1002, "原因 2b"},
{1002, "原因 2c"},
{1003, "原因 3"},
问题:对开发者不太友好,因为他还需要去解析字符串。。。
大家看下是否有更好的设计?