Error-management

You throw exceptions and you never handle any of them? Tsk tsk tsk.

I've generally assumed that exceptions being thrown is bad - most of the time in my game, an exception is going to be due to either a software or data error (i.e. bad levels data, or a bug).

So usually I'd create a class, throw it containing a string and some other stuff, and catch it somewhere near the top (outside the main loop).

I'd log the error, display it to the user if possible, and clean & tidy up, closing down graphics and sound etc to try not to leave the system in a funny state (not necessarily in that order).

I might (depending on how many of these errors exist) create a base class with a virtual method returning the description of the exception, which is overridden in subclasses with whatever data I need to contain.

Mark

Quote:

Original post by Fruny You throw exceptions and you never handle any of them? Tsk tsk tsk.

Where did I state that I never handle my exceptions? It's just that I think it's pretty overkill to throw an exception just because a simple texture is missing. I'm rewriting the tracer now so just the low-level functions throws exceptions and all the other errors (like missing textures / shaders) just pops a warning on my warningstack and my engine will try to ignore the missing resource

To detect faulty code, I use assert(), unit tests, and functional tests.

To detect faulty data or run-time errors, I use good range checking and either return an error code, or throw an execption (which gets caught and displayed or logged somewhere along the way).

To detect faulty user input, I use input validation code that has custom UI to describe to the user what's wrong, and put the cursor where he/she needs to correct it.

These are three very different things.

assert() is a god-send.

As far as games are concerned, I've always liked the fallback approach. If the code encounters a problem, fall back to an alternative that works. No error, just a note in the log. Only time you throw exceptions is when theres no way to continue, which usually results in a message window and/or program termination.

Yes, i've done that right now.. if there's a texture missing, just create a warning and render the objects using that texture without binding it