Roy Wood wrote:
[snip]
Anybody else have any thoughts on the whole topic of error handling? I
know that I spend a significant portion of my code checking on errors, so
this is an important topic.
I like exceptions, but you do have to be aware of the performance/size
hits. And of course, the bloaty-code gcc issues Sam mentioned. Sigh.
Paul Pedriana (from Maxis) has an article on his homepage which contains
a good explanation of the runtime overhead when using exceptions (it’s
for Visual C, but I’d guess most compilers generate similar stackframe
code). URL is http://www.ccnet.com/~paulp/GDCPP/GDCPP.html
My ideal exception class only contains a text message, and easy
formatting constructor for building up the message. eg:
if( !coolandgroovy )
throw FileErr( “Couldn’t load ‘%s’\n”, filename );
Note, no extra programmer info (file, line number) to be seen.
My rationale for omitting debug information:
The code to handle the error should be as small and unobtrusive as
possible. If you can get away without using braces (as above), so much
the better. You don’t want to interrupt the main flow of your code with
lots of elaborate diagnostics. Keeping the errorhandling out of the
algorithm is what exceptions are supposed to help with.
The message text should be unique enough to identify where the error
occured, so you can go in and set a breakpoint (it is a repeatable
error, right ;-).
The message should be geared up for the end user - if it’s something
technical or obscure, tack an error code on the front (eg “GFX001 - Your
video card is about to explode”) so your users can have something useful
to report (instead of “I got some graphics error… I forget what the
messagebox said…”).
Works well for me, YMMV.
Ben–
Ben Campbell (Antipodean Straggler)
Programmer, Creature Labs
ben.campbell at creaturelabs.com
www.creatures.co.uk