什么时候使用错误代码？

Question

在支持异常对象(Java,C#)的语言中,何时使用错误代码？在典型的企业应用程序中,错误代码的使用是否合适？

许多众所周知的软件系统使用错误代码(以及相应的错误代码引用).一些示例包括操作系统(Windows),数据库(Oracle,DB2)和中间件产品(WebLogic,WebSphere).错误代码提供哪些好处？使用错误代码有什么缺点？

Answer 1

WITHIN程序,应该采用异常而不是错误代码.但是,异常不能传播到程序之外.每当错误必须离开程序时,您将收到错误消息或错误代码.

对于简单的事情,总是人为操作的错误消息没有代码是好的.如果没有给出错误代码,您可以说"找不到文件".但是,如果它可能是另一端的另一台计算机,那么您应该另外提供错误代码.当您将其更改为"未找到文件<x>"时,您不希望破坏其他系统.

Answer 2

我不认为我曾经在.Net中使用过错误代码,除非在一种情况下 - 当我创建一个我知道将从另一个应用程序调用的控制台应用程序时.这个其他应用程序必须知道控制台应用程序何时失败,以及出了什么问题.因此,当你知道你的程序将被其他程序调用时,你需要一种结构化的方式让他们理解错误.

那就是说,我当时是.NET的新手,从那时起就从未使用过错误代码.

作为一个侧面说明,作为一个Windows的人,很高兴能够填写错误代码并提出知识库文章,所以错误代码结合良好的文档和找到它的能力=来自用户的好感觉.

Answer 3

Web服务接口很常见.返回带有描述的代码非常简单和标准.

我同意,大多数情况都是旧学校

我说最大的缺点就是代码的质量.您必须添加更复杂的逻辑来管理错误代码,同时冒泡异常而不必使用方法参数或返回值.

您还必须添加"IF"以检查返回的代码是否为SUCCESS,而异常直接转到错误处理块.

Answer 4

当需要将错误传达给用户时，我经常使用错误代码，因为它们可以国际化。例如，在编译器中，如果用户代码中存在错误，则可以在编译器后端发出错误信号，而前端可以将它们本地化为特定于文化/语言的字符串以供用户使用。然而，出于此目的，枚举可能比原始整数更好。

我还使用它们为应用程序创建了“错误报告”框架。当异常被抛出时，它们会被抛出一个错误代码，当异常冒泡时，该代码被（连同日志）发送到中央服务器。该代码有助于组织数据库，因此我们可以检查与特定错误相关的日志。

最后，在其他几个答案中提到，错误代码是容易和语言无关的谷歌（认为Windows错误代码/ MS KB文章），这样的错误代码有什么地方出了错的描述可能是为最终用户提供更好的一种技术产品。

错误代码的想法很有用，但 IMO 它们属于异常成员或 IErrorReporter 接口的参数，或者比方法返回值更重要的东西。

Answer 5

我是堆叠溢出的新手,但......

我认为错误代码倾向于用于处理错误情况,这些错误情况需要最终用户参与纠正某种情况.如果您的代码由另一个开发人员维护,则异常是可行的方法.但是,在出现问题的情况下:

然后错误代码可能有意义.例如,如果您的应用尝试代表最终用户登录数据库,但数据库无法进行身份验证(数据库处于脱机状态,电缆已拔下),则错误代码/描述组合可能有助于结束 - 用户纠正问题.

再次在开发人员/工程师级别,他们将能够触摸源代码(传统的调试和测试技术)并对其进行修改,使用异常.

希望这可以帮助...

--jqpdev