定义错误代码、数字还是字符串？答案

【问题标题】：define error code, number or string?定义错误代码、数字还是字符串？
【发布时间】：2014-01-21 18:42:20
【问题描述】：

当我使用企业应用程序时，我通常会遇到一些需要咨询帮助台的错误。我发现许多应用程序仍然倾向于使用数字作为错误代码，而不是人类可读的字符串。鉴于大多数企业应用程序都是用 java/C# 等现代语言编写的，我无法弄清楚使用数字错误代码有什么好处。

所以问题是，对于企业应用程序，是否有一种通用的用于定义错误代码的模式？是否有任何原因号优于字符串？

顺便说一句：我理解使用 REST API 的应用程序可能使用 http 状态码作为错误代码，这被理解为 http 状态码本身就是数字。但对于其他人，我不明白

【问题讨论】：

通常错误代码与错误字符串一起（即映射到），不是吗？
是的。错误代码通常映射到一些描述。所以问题是，为什么我们需要用户在令人生畏的文档或 wiki 中查找一些表格以了解魔术数字错误代码的含义？为什么不直接使用简洁的字符串作为错误码呢？

【解决方案1】：

同时拥有代码、数字或其他代码通常很方便，和是人类可读的。

代码使机器很容易知道发生了什么（并作为人类的简写），并且与语言和语言环境无关。

【讨论】：

谢谢戴夫。独立于语言环境是一个好点。但我认为数字对于机器来说并不像 Java/C# 这样的语言更容易，字符串操作是微不足道的。数字错误代码的问题在于它与您的代码紧密耦合。例如，如果您的应用程序是可插入的，那么每个插件都必须知道其他插件占用了哪些错误代码。字符串错误码没有这个问题，创建命名空间很容易。
@zx_wing 字母数字代码也被简单地命名空间。本地化或数据库存储的消息可能会在任意时间更改。解析错误消息是灾难的根源，并且从长远来看是不可维护的。当您可以进行简单查找时，您不必解析任何内容。

【解决方案2】：

错误代码以及提供更多信息的字符串的最大好处是，即使您的代码已被翻译成您可能看不懂的另一种语言，也可以查找它们。

下一个最大的好处是，如果有人编写了读取您的错误消息的代码（也许是您自己的公司，以帮助人们管理您的应用程序），那么拥有一个非常消息开头的错误代码。这既可以加快他们决定要做什么的速度，也可以部分保护他们免受您以后可能会改写消息的风险（这会打乱搜索消息文本的尝试）。

只要你坚持下去，任何约定都可以奏效。如果您正在考虑长期和多个产品，您可能希望代码包含一些指示哪个代码（应用程序和/或库和/或其他模块）发出错误的指示，然后您希望能够快速找到该产品的支持表中的错误。

IBM 通常使用可适度识别的字母前缀来标识代码，并使用数字后缀来指示特定消息。其他公司可能会采取不同的做法。

【讨论】：

能否将我链接到 IBM 的错误代码约定？那是公开的吗？我也在考虑使用字母前缀为不同的组件创建命名空间，以避免插件之间的冲突，因为数字错误代码是平的。但是一个很好的问题是，既然我已经开始使用字母前缀，为什么不直接使用字符串作为错误代码呢？
正如我所说，其他公司可能会采取不同的做法。我对使用字符串的犹豫是有风险的，无论你多么小心，一些程序员都会设法选择一个在某种语言中是粗鲁的字符串。选择少量前缀比选择大量消息标识符要容易得多。（避免元音也不能完全解决这个问题。想想如果你遇到了 NLCALCWTF 表示的错误，你会有什么感觉。）
emm，“NLCALCWTF”启发了我关于与语言无关的知识。通常很难用简洁的字符串来描述错误。所以它最终变成了神奇的缩写或冗长的句子。

【解决方案3】：

我最近遇到了类似的问题，我决定使用以下规则：

你可以争论第二条规则的必要性，因为你可以有尽可能多的错误类型。但是，如果您的系统正在增长，迟早您会发现需要引入新类型的错误，这将需要修改您的 API，这并不总是可能的，即使是这样，也可能不是很容易，因为您将拥有修改所有客户端。在这种情况下，枚举错误代码列表更容易维护。

【讨论】：