Error handling

Create a static function in your CError class that looks like

static void CError::SetError(DWORD id, char * errMsg);
(you might want to alter the void return to something useful for your calling code, but not sure how you really want it)

Assuming that you create the CError object somewhere you could call the static function whenever an error occurred in your code like so

result = CError::SetError(errID,"Hello the program is out of memory");

Then within SetError you could perform you switch statment, or store the error to process it at another time(if this is possible for you).

If you assess the error in the static function you would no longer need a struct for anything.

Hope this help a little.



Games are dreams of reality!

I'm curious, why not just handle the error in the function where it occured and return a bool value for success or failure? Requiring every piece of code that calls that function to handle the error causes a lot of code duplication and can easily lead to bugs where the error isn't displayed.

Will there be occasions where you don't want to display the error?


- Houdini

Edited by - Houdini on November 26, 2001 12:47:06 PM

It depends on what you call an error.

If by error you mean a non-ideal condition, like an NPC tried to move and hit a wall, that should be a return value.

If by error you mean you tried to open a file and couldn''t, exceptions are an exceptional method of error handling. Just be aware that they are slow, so exceptions should occur when the user is going to be seeing the error message and the program is going to basically be halting after that. Exceptions are great because you can (if you choose) have a single error handler outside your game loop, so you only have error-handling code in one place.

If by error you mean a programmatic error, e.g. you expect a function to have input values between 0 and 10 and your input value was outside that range from the calling function, you should assert. These get compiled-out for release builds, and stop instantly in the debugger for debug builds. If you have a problem with full-screen debugging, you can override assert to throw an exception (but only in debug builds).

Thanks a lot everybody, it really helped!
Another question then, if I would use dtomes way of doing it, is it okay to register the error class object as a global or will every class that uses the errorhandler register its own locally?

//Swede

Swede,

In general if you make that static function in the CError class you would not need to make a global class object and ideally you could just call CError::SetError(...,...) function without creating a CError class. Since it is a static function it will "live" and be callable without actually making a class object.

--Tome

Games are dreams of reality!