Question

As you all probably noticed, errors from different programs you get nowadays always have that error id number, that actually means what happend.

I was thinking maybe it’s a good idea to have a Dictionary<int,string>, when int is the error id, and the string is a description of what occurred.

For example:

ErrorID: 404
Description: Page not found

I’m asking this because I found a downside, and not sure if it is a big deal (maybe I just don’t know how it’s done).
As a programmer, once you catch an exception, how exactly would you associate it with the error id? (so you could eventually provide the user with the Description for why his operation could not work out).

Thank you.

Answer 1

You are trying to transpose the good old’error code pattern. This is a good practice when you are dealing with exception-less languages(C for example) or black-box/remote process (HTTP request).

In .net, you can use exceptions which include an error message :

throw new Exception("File not found");

Or even create your own exceptions :

class FileNotFoundException : Exception
{
  public FileNotFoundException() : base("File not found") {}
}

Usage:

throw new FileNotFoundException();

So, the answer : it might be a good pattern to handle error codes for errors that don’t happen often. .NET dictionaries are fast, but there is an overhead. But your question is not that far from the i18n stuff.

The real question is : do you prefer error codes or exceptions ?