定义错误代码，数字或字符串？

Question

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

所以问题是，对于企业应用程序，是否有一种常用的模式来定义错误代码？是字符串首选的原因吗？

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

Answer 1

通常方便的是，将代码，数字或其他，和设置为人类可读的。

该代码使机器可以轻松了解发生的情况（并作为人类的简写），并且与措辞和区域无关。

Answer 2

错误代码的最大好处 - 以及更多信息性字符串 - 即使在您的代码被翻译成您可能无法阅读的另一种语言后，也可以查找它们。

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

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

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

Answer 3

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

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

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