25

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

许多众所周知的软件系统使用错误代码(和相应的错误代码参考)。一些示例包括操作系统 (Windows)、数据库(Oracle、DB2)和中间件产品(WebLogic、WebSphere)。错误代码有什么好处?使用错误代码有什么缺点?

4

11 回答 11

21

程序中,应始终使用异常而不是错误代码。但是,异常不能传播到程序之外。任何时候错误必须离开程序,您都会留下错误消息或错误代码。

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

于 2010-05-08T04:02:01.663 回答
11

我认为我从未在.Net 中使用过错误代码,除非在一种情况下——当我创建一个我知道将从另一个应用程序调用的控制台应用程序时。这个其他应用程序必须知道控制台应用程序何时失败,以及出了什么问题。因此,一个合适的例子是当您知道您的程序将被其他程序调用,并且您想要一种结构化的方式让他们理解错误时。

也就是说,当时我是 .NET 的新手,从那以后就再也没有使用过错误代码。

作为一个旁注,作为一个 Windows 人,很高兴能够输入错误代码并提出一篇知识库文章,因此错误代码与良好的文档和查找它的能力相结合 = 用户的好感。

于 2010-05-08T02:44:15.697 回答
9

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

我同意大多数情况都是老派

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

您还必须添加一个“IF”来检查返回的代码是否成功,而异常则直接进入错误处理块。

于 2010-05-08T02:58:07.790 回答
6

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

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

最后,正如其他几个答案中所提到的,错误代码很简单,并且与谷歌语言无关(想想 Windows 错误代码/MS KB 文章),因此带有错误描述的错误代码可能对最终用户更好一种技术产品。

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

于 2010-05-08T02:45:54.460 回答
6

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

我相信错误代码往往用于处理需要最终用户参与纠正情况的错误情况。如果您的代码要由另一个开发人员维护,那么例外是要走的路。但是,在出现问题的情况下:

  • 在您的应用程序运行的环境中

  • 在您的应用程序和其他一些实体(Web 服务器、数据库、套接字等)之间进行通信

  • 设备或设备驱动程序指示(可能是硬件故障?)

那么错误代码可能有意义。例如,如果您的应用程序试图代表您的最终用户登录数据库,但无法访问数据库以进行身份​​验证(数据库处于脱机状态,电缆已拔出),那么错误代码/描述组合可能有助于最终 -用户纠正问题。

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

希望这可以帮助...

--jqpdev

于 2010-05-08T04:06:51.637 回答
2

错误代码是老式的。它们几乎没有价值。

错误代码唯一可能的价值是它可以识别非常具体的情况。您可以为代码库中可能引发异常的每个点设置一个代码。这将允许您非常精确地缩小问题的范围。

但是没有人关心那个级别的细节。谁愿意维持这样的烂摊子。它会给您留下类似于“条件 A 和 B 但不是由于状态 S 而不是 C”的代码。尝试弄清楚这意味着什么,付出的努力比值得付出的更多。堆栈跟踪将更有价值地告诉您问题发生在程序的哪个位置。

在异常成为一种广泛使用的技术之前,我学会了对计算机进行编程。我很高兴我们有例外!

于 2010-05-08T02:41:51.550 回答
2

C#,可能还有 Java,支持更好的异常处理控制流,finally 关键字,这比使用错误代码更好一些。异常对象可以包含任何级别的详细信息,当然不仅仅是错误代码。所以异常对象更实用,但你可能会遇到一个不常见的情况,错误代码更合适。

FWIW,C++ 也支持异常对象。我不认为 C++ 支持 finally 关键字(尽管新的 C++ 可能只是可能),但在 C++ 中,您还必须避免在 catch 处理程序中返回之类的事情。

于 2010-05-08T03:17:52.900 回答
2

错误代码是在这样一个时代设计的,在这个时代,函数告诉调用者出了问题的唯一方法是为可以返回的一个或多个值分配特殊含义,而且通常只有一个本机整数左右。可用于返回该特殊值。

例如,在 C 中,“获取字符”例程以 ASCII 格式返回下一个字符值,但如果由于某种原因出现问题,则返回负值。然后,您有责任以某种方式返回给您的调用者,以便可以处理这种错误情况,并且必须返回等。

异常机制是处理“这是紧急情况,我们必须从代码中返回,直到有东西可以处理问题”的一种优雅方式。错误代码不如这个。

于 2010-05-08T17:52:54.110 回答
0

我编写了许多由其他(远程)应用程序使用的 Web 服务。当请求出现问题时,客户或多或少会坚持获取代码,这样他们就不必进行一些可怕的字符串比较来找出问题所在。

以 HTTP 结果代码作为这种行为的一个很好的例子。“200”意味着快乐,“300”可以是任何一种方式,“400”或“500”意味着开始吓坏了。

于 2010-05-08T07:47:14.000 回答
0

错误代码用于如果您想将它们发送给用户。如果不是,请使用异常。

于 2010-05-08T17:59:49.117 回答
0

有时您不想在发生错误时向用户提供太多信息。例如,用户无法签署新合同。该错误消息仅说明“无法签署新合同”之类的通用内容。

这增加了支持用户认为不正确的情况的难度。如果您有错误代码,例如数字或首字母缩写词,它可能是错误消息的一部分。用户不知道这意味着什么,但支持人员可以查找它,然后可以检查拒绝新合同的具体原因是否确实是一个错误。

于 2021-11-09T13:29:58.270 回答