12

How, when developing a medium sized project, do you identify, create and maintain error codes?

I for the life of me can't think of a simple and clean method of doing so. Some of my ideas convert class names and method name into an integer string, but that is way to long to display to the user on top of the fact that method names and class names may change (hopefully not!). Others are just using an incrementing log system (ie. when ever I create a new error message, just add 1 to the last error message id). But that is just completely unorganized.

To be more specific I am talking about error code such as:

Error 401 Unauthorized.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
ahodder
  • 791
  • 3
  • 8
  • 16
  • 1
    error codes? Like "magic numbers"? For instance... ERROR 001. Then you go to a list and read ERROR 001 means that bla bla bla... Yes? – wleao Aug 02 '11 at 20:15
  • @wleao - Yessir. I will edit my question to encompass that. Thank you. – ahodder Aug 02 '11 at 20:15
  • read this: http://en.wikipedia.org/wiki/Magic_number_%28programming%29 – wleao Aug 02 '11 at 20:17
  • As you edited in your question. Take look at how they do it with http. I don't know if it's a good idea to use magic numbers at all. However, if you're really willing to do it, follow their concepts. For instance, they have a taxonomy of errors (do you have that?). – wleao Aug 02 '11 at 20:20
  • @wleao - not yet, but thanks to you and Péter Török, I will definetly be creating one. :) – ahodder Aug 02 '11 at 20:24
  • It was not obvious at all from the original question that you mean **HTTP status codes** by **error codes**. And I'm still not sure that you do... – Dan Aug 02 '11 at 20:34
  • @Dan Abramov - Not really; I'm working in java. The 401 error was just the first that came to mind. – ahodder Aug 02 '11 at 20:41
  • Ah. But then it's just a part of HTTP standard which is kinda old and is meant to be fast (also, obviously it is plain *dangerous* to send stack traces in this case). In Java, you typically use exceptions and don't use error codes at all. – Dan Aug 02 '11 at 20:45
  • @Dan Abramov - With the knowledge that sending stacktraces is dangerous, how would I send the bug/crash report back to me? – ahodder Aug 02 '11 at 20:54
  • No no no. I meant you don't want to send you *webapp* stacktraces to end users so that's why simple HTTP codes are returned. You already have stack traces on the servers (which you can log, mail, whatever). But for *client* applications there is *absolutely* no sense in error codes as they won't help you debug the potential problem. – Dan Aug 02 '11 at 20:56
  • @AedonEtLIRA let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/971/discussion-between-dan-abramov-and-aedonetlira) – Dan Aug 02 '11 at 20:57
  • http://www.useit.com/alertbox/20010624.html – jk. Feb 07 '12 at 23:10

5 Answers5

17

No.

Error codes are an anachronism, they stem from ye olden days when output was really hard and expensive, and the only way to signal an error condition may have been through a bunch of front panel lights: pdp11/70 front panel

These days, we have mature exception handling built into pretty much every mainstream language. Use it. Give the user information they can work with; don't bother them with technical blah-blah, but rather tell them roughly what went wrong and what they can do about it. For logging, just give your exceptions descriptive names, and log the name. Easier to remember, and also easier to find using grep or similar search tools.

The exception is, of course, when you're programming for situations where output is still hard and expensive, such as embedded systems or network protocols. HTTP still uses numeric response codes because they are extremely easy to parse efficiently - in some situations, reading just the first digit can tell you enough already, and you can discard the rest of the packet.

tdammers
  • 52,406
  • 14
  • 106
  • 154
  • Thank you for the detailed answer, that makes a lot of sense and is good to know. – ahodder Aug 02 '11 at 20:47
  • Your use of illustration matches your argument perfectly. I've read about PDP-11's forever. But this is actually the first one I've ever seen. Thanks. – Mike Owens Aug 02 '11 at 21:26
  • 2
    Inside of code, I'd rather handle an error code and I'm not that old. – JeffO Aug 14 '11 at 02:55
  • @Jeff: Anything you can do with error codes can also be done with exceptions, and then a bit more. If you want to mimick error codes with exceptions, all you need to do is throw instead of returning the error code, and catch instead of compare the return value against E_OK (or whatever the OK response is). To be fair though, C doesn't have real exceptions, and longjumps aren't as convenient, so if you're doing C, you're somewhat excused. – tdammers Aug 14 '11 at 08:14
  • @Mike: The image is from the wikipedia article on the PDP-11 series; if that isn't easy to find I don't know what is. – tdammers Aug 14 '11 at 08:15
  • I have used those switches to enter a boot-loader and restart a PDP-11. – kevin cline Feb 07 '12 at 23:17
  • I absolutely agree that descriptive error messages are highly useful to an end user and should be well utilized. I completely disagree that error codes are unneeded. Error codes provide useful advantages for reporting, can be easily categorized if implemented under a rationale numbering scheme, and provide some structure for reasoning about errors in general. I use both error codes and descriptive messages and have always found both beneficial. – Anthony Gatlin Jul 10 '18 at 03:19
7

You should check out how error/status codes are organized in common protocols such as HTTP. They reserve distinct ranges for different types of statuses/errors. This makes it easier both for users to identify an unknown status code, and for developers to assign a code for a new kind of error which hasn't been handled before.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
  • Add to your answer the taxonomy thing. It will make things easier to manage and maintain the errors. – wleao Aug 02 '11 at 20:22
3

I'm going to assume a procedural context (C). If you have objects an error object is usually better, whether exception or not.

You should use error codes local to each module. For a library you can have a special header listing the error codes, with number 1, 2 etc (or -1, -2 if you prefer). Make sure to always return one of these codes, e.g. translate errno into your own codes. If you have multiple layers of modules, translate at each step (or predefine a range for the deeper error, e.g. values 1001 - 1050 is from that other module).

It is also important that you provide a means for translating the code into a string. You should never report only the code, that only leads to frustration. Actually pretty much any code in your application should come with a string translation function. For example libc typically has strerror and strsignal, but sadly lacks strwaitstatus.

Per Johansson
  • 311
  • 3
  • 9
3

Sorry, why using error codes at all?
Catch the exception, log it and offer to send a report if the program can't recover.

(Assuming your language supports exceptions.)

The only relevant information that might help you fix the bug is the stack trace which you don't get with an error code. (I'm also assuming you want to use error codes for error reports and not to throw them into a user's face.)

Dan
  • 2,902
  • 1
  • 25
  • 30
  • That is very true, and I do that, but what would I tell the users? I'm sure they would be livid if they were peddling along and the application just dies, no explanation or anything to fume at. – ahodder Aug 02 '11 at 20:19
  • 6
    I think there are at least three different things that get confused here. The first is codes used from-software-to-software, like in HTTP. The second are codes that users can use in an error report (like incident numbers). The last are messages that can be shown to the user. It may help to consider them as separate things. – Darien Aug 02 '11 at 20:29
  • 2
    One big reason to use error codes is when you're building a back end application. It's a lot easier and more elegant for a client program to interpret and respond to a code than to an error message or stack trace. Not all errors are from bugs. – Kaypro II Aug 02 '11 at 20:34
  • 1
    Exceptions are very tough to get right! See links in: http://programmers.stackexchange.com/questions/97874/why-should-i-write-all-the-statements-within-try-catch/97992#97992 – Coder Aug 02 '11 at 20:38
  • @Coder: your example abuses exceptions. You should **catch what you expect to be thrown**. Most methods don't need to expect even a single exception being thrown. It's totally programmer's responsibility to decide *what* to handle and I agree it may be [hard to get it right](http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx). – Dan Aug 02 '11 at 20:43
  • @Dan: See all 4 links at the top of the post. – Coder Aug 02 '11 at 20:46
  • @Coder: This is still very subjective, don't you think? Error codes are much uglier to me, at least in .NET/Java code. – Dan Aug 02 '11 at 20:50
  • @Dan: They are, incredibly ugly... But I came to conclusion that every time I want to resort to exceptions, I can't be sure I'm handling all the cases, and that after catching I can continue normally. Unless it's something like good old int.Parse FormatException, the exceptions are nightmare. Unless you bail from the application. But in that case abort(); works just fine. – Coder Aug 02 '11 at 21:09
  • @Coder: but you really don't *have to* handle *all* the cases. How is this different from the error codes? Do you handle all of them? – Dan Aug 02 '11 at 21:11
  • @Coder let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/972/discussion-between-dan-abramov-and-coder) – Dan Aug 02 '11 at 21:11
-1

Here is my unique system for ErrorCodes: I actually thinks that ErrorCodes are good. You still need to have some text description for the error, but Error Code help you to find the place in the code itself that catches this error.

I use this method here https://breakpo.blogspot.com/2020/05/simple-system-to-track-errors-in-code.html

YYYYMMDD.XXXHHII

This give a full uniqueness for the Error Code number among the team. XXX is a unique number each one of the developers in the team have.

So an error code could be: 20190412.1001643 For programmer number 100, on the 12th of April 2019 at 4:43PM

This allows me to know how old is the code, and who to blame in no time :-)

aviv
  • 99
  • 1