Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

Edit 1:

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

Error 401 Unauthorized.

share|improve this question
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 2 '11 at 20:15
@wleao - Yessir. I will edit my question to encompass that. Thank you. –  AedonEtLIRA Aug 2 '11 at 20:15
read this: en.wikipedia.org/wiki/Magic_number_%28programming%29 –  wleao Aug 2 '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 2 '11 at 20:20
@wleao - not yet, but thanks to you and Péter Török, I will definetly be creating one. :) –  AedonEtLIRA Aug 2 '11 at 20:24

4 Answers 4

up vote 13 down vote accepted


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.

share|improve this answer
Thank you for the detailed answer, that makes a lot of sense and is good to know. –  AedonEtLIRA Aug 2 '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 2 '11 at 21:26
Inside of code, I'd rather handle an error code and I'm not that old. –  JeffO Aug 14 '11 at 2: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 8: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 8:15

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.

share|improve this answer
Thanks, I will look at those. –  AedonEtLIRA Aug 2 '11 at 20:20
Add to your answer the taxonomy thing. It will make things easier to manage and maintain the errors. –  wleao Aug 2 '11 at 20:22

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.)

share|improve this answer
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. –  AedonEtLIRA Aug 2 '11 at 20:19
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 2 '11 at 20:29
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 2 '11 at 20:34
Yes, thank you Darien. That's my opinion =) –  wleao Aug 2 '11 at 20:35
Exceptions are very tough to get right! See links in: programmers.stackexchange.com/questions/97874/… –  Coder Aug 2 '11 at 20:38

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.

share|improve this answer
fantastic detail, thank you. This is actually really helpful. –  AedonEtLIRA Feb 8 '12 at 2:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.