定义错误码，是使用数字还是字符串？

Question

当我使用企业应用程序时，通常会遇到一些错误需要咨询帮助台。我发现许多应用程序仍然倾向于使用数字作为错误代码，而不是可读的字符串。鉴于大多数企业应用程序都是用像Java/C＃这样的现代语言编写的，我无法想象使用数字错误代码的好处在哪里。

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

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

- zx_wing

---

通常一个错误代码会与一个错误字符串相关联，不是吗？ - peter.petrov

是的。错误代码通常映射到某些描述。所以问题是，为什么我们需要用户在令人生畏的文档或维基中查找魔术数字错误代码的含义？为什么不直接使用简洁的字符串作为错误代码？ - zx_wing

Answer 1

通常同时具备代码（数字或其他形式）和人类可读性更方便。

代码使机器容易知道发生了什么（也可以作为人类的速记），并且不受措辞和地区的影响。

- Dave Newton

---

谢谢Dave。独立于语言环境是一个很好的观点。但我认为对于像Java/C#这样的语言来说，数字并不比字符串更容易处理。数字错误代码的问题在于它紧密地耦合了你的代码。例如，如果你的应用程序是可插拔的，那么每个插件都必须知道其他插件已经占用了哪些错误代码。字符串错误代码没有这样的问题，很容易创建命名空间。 - zx_wing

@zx_wing 字母数字代码同样具有命名空间。本地化或数据库存储的消息可能会在任意时间更改。解析错误消息是灾难的配方，且长期维护性差。当你可以进行简单的查找时，就不应该解析任何内容。 - Dave Newton

Answer 2

错误代码的最大好处--以及更具信息性的字符串--在于即使您的代码已被翻译成您不懂的另一种语言，它们仍然可以被查找到。其次，如果有人编写了读取您的错误消息的代码--也许是您自己的公司，以帮助人们管理您的应用程序--那么在消息开头加上错误代码对他们来说是非常有帮助的。这既加快了他们决定如何处理问题的速度，也在一定程度上保护他们免受您稍后重新表述消息（这会破坏搜索消息文本的尝试）的风险。

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

IBM通常使用一个相当可识别的字母前缀来标识代码，并使用数字后缀来表示特定的消息。其他公司可能会以不同的方式进行操作。

- keshlam

---

你能给我提供IBM的错误代码规范链接吗？这是公开的吗？我还在考虑使用字母前缀为不同组件创建命名空间，以避免插件之间的冲突，因为数字错误代码是平面的。但一个好问题是，既然我已经开始使用字母前缀，为什么不直接使用字符串作为错误代码呢？ - zx_wing

就像我说的，其他公司可能会有不同的做法。我犹豫使用字符串的原因是，无论你多么小心，某些程序员仍然会选择某些语言中粗鲁的字符串。选择少量的前缀比选择大量的消息标识符要容易得多。（避免元音并不能完全解决这个问题。想想如果你收到由NLCALCWTF表示的错误会感觉如何。） - keshlam

“NLCALCWTF”启发我关于语言无关性的探讨。在描述错误时，往往难以用简洁的字符串来表达，因此只能使用神奇的缩写或冗长的句子。 - zx_wing

Answer 3

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

• 将相似的错误分组（在Java中，这些将是异常类）
• 每个错误都有一个枚举值来标识它（即错误代码）
• 每个错误都有人类可读的消息
• 错误可以选择性地具有原因（在许多情况下，您的错误是由于发生了其他错误而生成的，而该错误是原因）

你可能会对第二条规则的必要性提出质疑，因为你可能会有尽可能多的错误类型。然而，如果你的系统不断增长，迟早你会发现需要引入新的错误类型，这将涉及修改你的API，而这并不总是可能的，即使可能，也可能不是很容易，因为你将不得不修改所有客户端。在这种情况下，枚举错误代码列表更容易维护。

- Tomasz Bekas