The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How to handle errors in my application

Hi !

Through out my whole application, I need to display message boxes to inform the user when an error happened. For now, each method which encounters an error just pops a mesage box up displaying a message.

I'd like to add to the message an error code, to simplify the user bug report.

I don't really know how to make sure that each error code is unique. Should I have a error management class (a singleton) which knows all possible errors and keep an enumeration of each error, and each time a method has to display an error, it actually calls the error management class with the enumerated type of the error and the error management class will take care of displaying the message box with the message and the error number ?

Or do you have another/better way of solving this ?

Jérôme
Jerome
Saturday, April 02, 2005
 
 
Why an error nubmer, why not a simple string.
So you can say "can't open file" instead of 5.
Beyond that, I recommend on using exception for error reporting, as they make centralized reporting much easier, and can carry far more information.
Ayende Rahien Send private email
Saturday, April 02, 2005
 
 
I'm not sure why the solution has to be any more complicated than this. Not everything in life has to be fancy:

namespace MyStupidApp
{
  enum ErrCode
  {
    ERR_UNDERWEAR, ERR_DOG, ERR_GROIN // etc...
  };

  struct ErrCodeRecord
  {
    ErrCode Code;
    char*  pDescription;
  };

  const ErrCodeRecord ErrCodeTable[] =
  {
    {ERR_UNDERWEAR, "My underwear is on fire!"},
    {ERR_DOG,      "Somebody ate my dog!"},
    {ERR_GROIN,    "My groin smells slightly odd!},
    // ...
    {0xffffffff, ""} // List terminator
  };
}
John Foxx
Saturday, April 02, 2005
 
 
oops, sorry, a few typos (missing colon & that screwed-up terminating record), but you get the idea...
John Foxx
Saturday, April 02, 2005
 
 
John, I get your idea. I had something similar in mind.

Ayende : I have to admit I never used exceptions in my code, so I don't really see how I should use them to centralized error management. Any link which would help ?

As a side note : my goal is not to jsut display a error number without any text, but both : thus, the user can report a bug to us just by telling us the error number, instead of having to duplicate the text !

Jerome
Jerome
Sunday, April 03, 2005
 
 
Hey Jerome,

This is a personal preference but I shy away from using exceptions for anything except fatal exceptional conditions (divide-by-zero, Ethernet hardware died, SQL server croaked, that sort of thing). I dislike using them for "normal" return codes because your code becomes so garbaged up with try/catch blocks that it's no longer C++ or Java or whatever, it's now the try/catch language. In practice, I vastly prefer this:

RetCode = SomeObj.SomeFunc(Param1, Param2, &Result);

to this:

try{
  Result = SomeObj.SomeFunc(Param1, Param2);
}
catch(...){
  // Ret code is in the exception object
}

because a lot of times you don't want an error to break the flow, so you end up enclosing each !@#$%ing line of code in a try/catch block. Just my opinion, but I think this is an abuse of the exception concept.

I would say, don't go digging under rocks to find complex ways to do simple things. Rather, seek simple ways to do complex things. Even Bjarne Stroustrup says people are getting carried away w/the whole OO thing & trying to solve every problem by building a huge scaffolding of hierarchical class types.

Hope this helps & doesn't confuse things further!
John Foxx
Sunday, April 03, 2005
 
 
"Why an error nubmer, why not a simple string."

Depends on the purpose.  If the info is for the user to report TO YOU, it's better to have an error number.  It's easier for them to write down and they're less likely to mis quote it.  (Lke the users who say "yeah, I've got Windows  96. YES, definitely Windows 96.


The TEXT is there to let the user know what's going on. the Error NUMBER is there for debugging.  Techies need a number. Non-techies just need to know that they haven't triggered a game of Thermonuclear Warfare.
Mr. Analogy (uISV owner} Send private email
Sunday, April 03, 2005
 
 
Re: Try-Catch vs. error numbers

I have a different perspective as a Java developer (and C++, C, VB, Pascal before that).

Even though try-catch can get a little wordy, the alterative is something like:

Retval = SomeFunc.doSomething()
if (Retval == SOME_ERROR_CODE) {
  ...
}
else if (Retval == SOME_OTHER_ERROR_CODE)
{
  ...
}
else if (Retval == OK_CODE)
{
  ....
}

instead of:

try {
  Retval = SomeFunc.doSomething();
  ...
}
catch (SpecificException e1) {
  ...
}
catch (GeneralException e2)
{
  ...
}
finally {
  // code to invoke regardless of the success or failure
}

Your exception class can certainly store an error number as well for user error reporting.
Dave C Send private email
Monday, April 04, 2005
 
 
In my .net error handling I created a class that represents an error with properties such as error code, message, return code, reason code, issuer

I then had shared methods (in vb.net speak) that represent the unique errors. Each has its own parameters defined and the method simply returns an error object.

e.g.
Dim zErr as MyError = MyError.ERR01(myContext,andMore)
Harry McBain
Tuesday, April 05, 2005
 
 
Dave C, how about:

switch(SomeFunc.doSomething()) {
  case SOME_ERROR_CODE:
    ...

Seems to be the neatest of the lot of them imho!
i like i
Wednesday, April 06, 2005
 
 
Sorry I missed what language you where writing in, it seems that your not realy interested in the "number" except as a shortcut to debug the code when users find bugs.

My first preference would be not to release buggy code :P
however given all the usual constraints and your likely to release buggy code anyway...

You could write a precompile step which translates a particular token in your code into a number from the sequence managed by the precompile step.  Thus each is unique and you don't need to manage them even when you move stuff.

Another method might be to hash line/file information where a particular "error" case is at runtime.  (for C/C++ using __LINE__, __FILE__)  you would need to be able to unhash it.

In our PL/SQL we make use of a table which provides a unique number and associates it with an Error message and a Correction message, like "Table <tname> is inaccessible", and "<towner> needs to grant <taccess> to <user>".  You then have to use the unique number in your code.
 
It's nice to be able to change your messages without having to recompile the code.
gorf Send private email
Thursday, April 07, 2005
 
 
An old way was to identify the location in the source code using __LINE__ and __FILE__ macros.

Another way is to include the entire call stack in the error report.
Christopher Wells Send private email
Saturday, April 09, 2005
 
 
Error codes are really useful if your app gets translated into languages you, your email or your customer's email system don't understand.

Which of the following bug reports is easier to understand:
1.        Result: a box saying 我不学习汉语
2. -or- Result: a box saying 我不学习汉语 (17)

And how about:
3.        Result: a box saying ??????
4. -or- Result: a box saying ?????? (17)
Jonathan
Monday, April 11, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz