什么时候适合使用错误代码？
在支持异常对象的语言（Java、C#）中，什么时候适合使用错误代码？在典型的企业应用程序中使用错误代码是否合适？
许多众所周知的软件系统都使用错误代码（以及相应的错误代码参考）。一些示例包括操作系统 (Windows)、数据库（Oracle、DB2）和中间件产品（WebLogic、WebSphere）。错误代码有什么好处？使用错误代码有哪些缺点？
In languages that support exception objects (Java, C#), when is it appropriate to use error codes? Is the use of error codes ever appropriate in typical enterprise applications?
Many well-known software systems employ error codes (and a corresponding error code reference). Some examples include operating systems (Windows), databases (Oracle, DB2), and middle-ware products (WebLogic, WebSphere). What benefits do error codes provide? What are the disadvantages to using error codes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
在程序中应该始终使用异常而不是错误代码。但是，异常不能传播到程序之外。每当错误必须离开程序时，您都会留下错误消息或错误代码。
对于简单的事情，总是人为操作的错误消息，没有代码就可以了。您可以说“找不到文件”而不给出错误代码。但是，如果另一端可能是另一台计算机，那么您应该另外提供错误代码。当您将其更改为“文件未找到”时，您不想破坏其他系统。
WITHIN a program one should always use exceptions instead of error codes. However, exceptions can't propagate beyond a program. Any time the error must leave the program you are left with error messages or error codes.
For simple things that will always be human-operated error messages without codes are fine. You can say "File not found" without giving it an error code. However, if it might be another computer on the other end then you should give error codes in addition. You don't want to break the other system when you change it to "File <x> not found".
我认为我从未在 .Net 中使用过错误代码，除了一种情况 - 当我创建一个我知道将从中调用的控制台应用程序时另一个应用程序。另一个应用程序必须知道控制台应用程序何时失败以及出了什么问题。因此，一个合适的例子是当您知道您的程序将被其他程序调用，并且您需要一种结构化的方式让它们理解错误时。
也就是说，我当时是 .NET 的新手，从那以后就再也没有使用过错误代码。
顺便说一句，作为一名 Windows 人员，能够输入错误代码并提出一篇知识库文章真是太好了，因此错误代码与良好的文档以及找到它的能力相结合 = 用户的良好感受。
I don't think I've ever used error codes in .Net except in one situation - when I was creating a console application that I knew was going to be called from another app. This other app had to know when the console app failed, and what went wrong. So, one example of when it would be appropriate would be when you know your program will be called by other programs, and you want a structured way for them to understand errors.
That said, I was a newbie to .NET at the time, and have never used error codes since.
As a side note, as a Windows guy, it's nice to be able to plop in an error code and come up with a KB article, so an error code combined with good documentation and the ability to find it = nice feelings from your users.
对于 Web 服务接口来说非常常见。返回带有描述的代码非常简单且标准。
我同意大多数情况都是老派的，
我想说最大的缺点是代码的质量。当异常冒泡时，您必须添加更复杂的逻辑来管理错误代码，而无需使用方法参数或返回值。
您还必须添加一个“IF”来检查返回的代码是否成功，而异常则直接进入错误处理块。
Very common for web service interfaces. It's very easy and standard to return a code with a description.
I agree that for most of the scenarios is old school
I'd say the biggest disadvantages it's the quality of code. You have to add more complex logic to manage error codes while exceptions are bubbled without having to use method parameters or return values.
You also have to add an "IF" to check if the returned code is SUCCESS or not, while exceptions goes directly to the error handling block.
我是堆栈溢出的新手，但是......
我相信错误代码往往用于处理错误情况，或者需要某种最终用户参与纠正情况的错误情况。如果您的代码由其他开发人员维护，那么异常就是最佳选择。但是，在存在问题的情况下：
在您的应用程序运行的环境中
您的应用程序与其他一些实体（Web 服务器、数据库、套接字等）
设备或设备驱动程序表明（可能是硬件故障？）
然后错误代码可能有意义。例如，如果您的应用程序尝试代表最终用户登录数据库，但无法访问数据库进行身份验证（数据库离线，电缆已拔出），则错误代码/描述组合可能会帮助最终用户用户纠正问题。
同样在开发人员/工程师级别，他们将能够接触源代码（传统的调试和测试技术）并修改它，使用异常。
希望这有帮助...--
jqpdev
I'm a newbie to stack overflow but...
I believe that error codes tend to be used or useful for dealing with erroneous situations that require an end-user of sorts to get involved to rectify a situation. If your code is to be maintained by another developer then exceptions is the way to go. However, in a situation where there is a problem:
in the environment that your application is running
with communication between your app and some other entity (web server, database, socket, etc)
that a device or device driver indicates (hardware failure maybe?)
then error codes may make sense. For example, if your app attempted to log into a database on behalf of your end-user, but the DB was unreachable for authentication (DB is off-line, cable is unplugged) then an error code/description combo might help the end-user rectify the problem.
Again at the developer/engineer level who will be able to touch the source code (traditional debugging and testing techniques) and modify it, use exceptions.
Hope this helps...
--jqpdev
当需要将错误传达给用户时，我经常使用错误代码，因为它们可以国际化。例如，在编译器中，如果用户代码中存在错误，则可以在编译器后端发出错误信号，而前端可以将它们本地化为特定于文化/语言的字符串以供用户使用。然而，对于这个目的来说，枚举可能比原始整数更好。
我还使用它们为应用程序创建“错误报告”框架。当抛出异常时，会抛出一个错误代码，当异常冒泡时，该错误代码会（带有日志）发送到中央服务器。该代码帮助组织数据库，以便我们可以检查与特定错误相关的日志。
最后，正如其他几个答案中提到的，错误代码对于 google 来说很简单且与语言无关（想想 Windows 错误代码/MS 知识库文章），因此错误代码和错误的描述可能会对技术产品的最终用户来说更好。
错误代码的想法很有用，但在我看来，它们属于异常成员或 IErrorReporter 接口的参数，或者比方法返回值更常见的东西。
I frequently use error codes when an error needs to be conveyed to the user, since they can be internationalized. For example, in a compiler, if there are errors in user code, errors can be signaled in the compiler backend, while the frontend can localize them into culture/language-specific strings for user consumption. Enums may be better for this purpose than raw integers, however.
I've also used them in creating an "error reporting" framework for the app. When exceptions were thrown, they were thrown with an error code, which, when the exception bubbled up, was sent (with a log) to the central server. The code helped organize the database so we could inspect logs related to a specific error.
Finally, as mentioned in a couple other answers, error codes are easy and language-agnostic to google (think Windows error codes/MS KB articles), so an error code with a description of what went wrong may be better for end-users of a technical product.
The idea of error codes is useful, but IMO they belong as exception members or as parameters to an IErrorReporter interface or something more ofthen than as method return values.
错误代码是老式的。它们几乎没有价值，甚至根本没有价值。
错误代码唯一可能的价值是它可以识别非常具体的情况。您可以为代码库中可能引发异常的每个点编写一个代码。这将使您能够非常精确地缩小问题范围。
但没有人关心这种程度的细节。谁愿意维持这样的混乱。它会给你留下一些代码，其含义类似于“由于状态 S，条件 A 和 B，但不是 C”。尝试弄清楚这到底意味着什么，付出的努力比值得付出的努力还要多。堆栈跟踪对于告诉您程序中发生问题的位置更有价值。
在异常成为一种广泛使用的技术之前，我就学会了计算机编程。我非常很高兴我们得到了例外！
Error codes are old-school. They are of little to no value at all.
The only possible value to an error code is that it can identify a very specific circumstance. You could have a code for each point in the code base that can throw an exception. This would allow you to narrow down very precisely what the problem must be.
But nobody cares about that level of detail. Who wants to maintain such a mess. It would leave you with codes that meant something like "condition A and B but not C due to state S". It's more effort than it's worth to try to work out exactly what that means. A stack trace will be more valuable in telling you where in the program the problem occurred.
I learned to program computers before exceptions were a widespread technique. I'm so glad we got exceptions instead!
C#（可能还有 Java）支持更好的异常处理控制流（finally 关键字），这使得事情比使用错误代码更好一些。异常对象可以包含任何级别的详细信息，当然不仅仅是错误代码。因此，异常对象更实用，但您可能会遇到不常见的情况，其中错误代码更合适。
FWIW，C++ 也支持异常对象。我不认为 C++ 支持 finally 关键字（尽管较新的 C++ 可能会支持），但在 C++ 中，您还必须避免诸如在 catch 处理程序中返回之类的事情。
C#, and probably Java too, supports a better exception handling control flow, the finally keyword, which makes things a little nicer than using error codes. An exception object can contain any level of detail, certainly much more than an error code. So the exception object is way more practical, but you might run into an uncommon case where an error code would be more appropriate.
FWIW, C++ also supports exception objects. I don't think that C++ supports a finally keyword (though the newer C++ whatevers just might), but in C++ you also have to avoid things like returning inside a catch handler.
错误代码是在这样一个时代设计的：函数告诉调用者出现问题的唯一方法是为可返回的一个或多个值分配特殊含义，并且通常只有一个本机整数左右。可用于返回该特殊值。
例如，在 C 中，“获取字符”例程返回 ASCII 中的下一个字符值，但如果由于某种原因出现错误，则返回负值。然后，您负责以某种方式返回到您的调用者，以便可以处理此错误情况，并且必须返回等。
异常机制是处理此问题的一种优雅方法“这是一个紧急情况，我们必须从代码中返回，直到有东西可以返回”。处理问题”。错误代码比这个差。
Error codes were designed in an age where the only way for a function to tell the caller that something went wrong was to assign a special meaning to one or more values of those which can be returned, and very frequently only a native integer or so was available for returning that special value.
For instance, in C the "get character" routine returns the next character value in ASCII, but returns a negative value if for some reason something went wrong. You are then responsible for returning to YOUR caller in a way so this error situation can be handled, and that must return etc.
The Exception mechanism is an elegant way to handle this "this is an emergency, we must return from code until something can deal with the problem". Error codes are inferior to this.
我编写了许多由其他（远程）应用程序使用的 Web 服务。当请求出现问题时，客户或多或少会坚持获取代码，这样他们就不必进行一些可怕的字符串比较来找出问题所在。
以 HTTP 结果代码作为此类行为的一个很好的例子。 “200”意味着快乐，“300”可以是任何一种，“400”或“500”意味着开始抓狂。
I've written many web services that are consumed by other (remote) applications. When things go badly with a request, customers more or less insist on getting a code, so that they don't have to do some horrific string comparison to find out what went wrong.
Take HTTP result codes as a fine example of this sort of behavior. "200" means happy, "300" could go either way, "400" or "500" means start freaking out.
错误代码适用于您想将它们发送给用户的情况。如果没有，请使用异常。
Error codes are for if you want to send them to the user. If not, use an exception.
有时您不想在发生错误时向用户提供太多信息。例如，用户无法签署新合同。该错误消息仅说明一些通用内容，例如“无法签署新合同”。
这增加了支持用户认为这是不正确的情况的困难。如果您有错误代码，例如数字或缩写词，它可能是错误消息的一部分。用户不知道这意味着什么，但支持人员可以查找它，然后检查拒绝新合同的具体原因是否确实是一个错误。
Sometimes you don't want to give too much information to the user when an error occurs. For example, a user is not able to sign a new contract. The error message only states something generic like "Cannot sign a new contract".
This adds difficulty to support cases where the user thinks this is not correct. If you have an error code, for example a number or an acronym, it could be part of the error message. The user wouldn't know what it means but the support staff could look it up and could then check if that specific reason for declining the new contract is indeed an error or not.