I'm working on an enterprise project which will be deployed in many SMBs and Enterprises.
The support for this project would be struggling and so I want to create a coding pattern for errors (Like HTTP status Codes). This will enable help desk people to refer to documents and troubleshoot the problems as soon as possible.

What are the best practices and recommendations to do this?
Any help to do this will be useful.

  • 2
    There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. And what have you tried so far. Commented Aug 28, 2013 at 7:29
  • Depends on how your business is structured. In C# we always gave the user the possibility to mail us the StackTrace or copy/paste it from the error message details (we had no tight security requirements).
    – Falcon
    Commented Aug 28, 2013 at 11:52

3 Answers 3


There is a difference between error codes and error return values. An error code is for the user and help desk. An error return value is a coding technique to indicate that your code has encountered an error.

One can implement error codes using error return values, but I would advice against that. Exceptions are the modern way to report errors, and there is no reason why they should not carry an error code within them.

This is how I would organize it (Note that points 2-6 are language agnostic):

  1. Use a custom exception type with an additional ErrorCode property. The catch in the main loop will report this field in the usual way (log file / error pop-up / error reply). Use the same exception type in all of your code.
  2. Do not start at 1 and don't use leading zeros. Keep all error codes to the same length, so a wrong error code is easy to spot. Starting at 1000 usually is good enough. Maybe add a leading 'E' to make them clearly identifiable for users (especially useful when the support desk has to instruct users how to spot the error code).
  3. Keep a list of all error codes, but don't do this in your code. Keep a short list on a wiki-page for developers, which they can easily edit when they need a new code. The help desk should have a separate list on their own wiki.
  4. Do not try to enforce a structure on the error codes. There will always be hard-to-classify errors and you don't want to discuss for hours whether an error should be in the 45xx group or in the 54xx group. Be pragmatic.
  5. Assign each throw in your code a separate code. Even though you think it's the same cause, the help desk might need to do different things in different cases. It's easier for them to have "E1234: See E1235" in their wiki, than to get the user to confess what he has done wrong.
  6. Split error codes if the help desk asks for it. A simple if (...) throw new FooException(1234, ".."); else throw new FooException(1235, ".."); line in your code might save half an hour for the help desk.

And never forget that the purpose of the error codes is to make life easier for the help desk.

  • I have never done this personally, but often you see "correlation ids" as well, error-instance-specific guids that are displayed to the user and also logged. That way, you can more easily find the exact error occurrence in the logs, more easily than with an approximate time and an error code.
    – xdhmoore
    Commented May 23, 2018 at 17:37
  • I suppose there's probably a way to include the error code within the correlation id so that it can serve as a human-readable error code for the help desk and as an error instance id for developers.
    – xdhmoore
    Commented May 23, 2018 at 17:40
  • 2
    My pattern is pretty similar. But instead of "E", I added a short of the app-part. Our documentation-framework has e.g. a Doc1234 while the Main-App can have IrS1234. So my helpdesk-coworkers are pretty fast with helping my users. Commented Oct 16, 2019 at 15:59
  • @Sjoerd why do you advise not keeping the error codes programatically?
    – kmb385
    Commented Jul 11, 2022 at 12:35
  • @kmb385 I assume you talk about point 3. Almost all code will depend on that file, and at the same time that file will change very frequently. That combination is a red flag for, among others, quick recompiles and should be avoided in any project of reasonable size.
    – Sjoerd
    Commented Jul 11, 2022 at 19:49

You first have to isolate the areas where errors might occur, and are user-visible. Then you can document them. Its that simple.

Well, simple in theory.. in practice errors can occur all over the damn place, and reporting them can turn nice code into a monster of logging, exception throwing and handling, and passing return values.

I would recommend a 2-step approach then. First is to log, log lots and lots.

Second is to determine the major components and their interfaces, and to define what major error cases these components can find themselves in. You can then log in a more visible manner when one of these errors (how you handle the error internally is up to you - exceptions or error codes make no difference here). A user will generally then see the error and go to the logs for more detailed information.

The same approach is used for web servers and your http error code example. If the user sees a 404, and reports it to support, they will look in the logs for the details of what was going on, which page was visited, when, and will glean any other info they can from where-ever else make sense, be in the DB, the network or the application.


I would go for custom exceptions with descriptive names and clear messages and throw those. It's a lot easier to use the existing exception infrastructure of a language than to build in support for passing error codes around and interpreting them.

  • 2
    I would appreciate the person who downvoted this answer from 1 to 0 to at least give a reason... Commented Aug 28, 2013 at 8:56
  • 2
    wasn't me downvoting (not that it matters, get over it), but I think there is existing support for return values in the language too.
    – gbjbaanb
    Commented Aug 28, 2013 at 9:05
  • 3
    It matters to me; if I'm wrong, I'd like to know so I can learn :-p How do you mean, existing support for return values? Wouldn't you have to write plumbing to differentiate a normal return value from an error code? Translating an exception to an error code at the boundary of a system is one thing, but juggling them inside your system is something that's generally advised against. I believe The Pragmatic Programmer mentions this sort of stuff. Commented Aug 28, 2013 at 9:15
  • 8
    I didn't down vote you(take it easy, otherwise everyone will have to repeat this:). If you had worked or called in service desk, it's a lot easier to just communicate a short number than an error message. An error message is guaranteed to change when it is communicated orally.
    – Codism
    Commented Aug 28, 2013 at 15:16
  • 2
    There's the ugliness of not understanding error code 12345 as opposed to a message "Disk full" -- Microsoft Windows updates sometimes fail, and I get error codes as opposed to messages. Googling them is not much help - just did this yesterday for Code 80070103 -- "Get help with this error" is a mess. Perhaps this is more a problem with Microsoft than the error-code approach, but in 2014 I think users shouldn't see error codes. Commented Oct 16, 2014 at 13:32

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