RE: [boost] Re: Runtime error reporting

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2001-03-20 18:10:17

> I don't see how put_text differs any from the thread implementation 
> that I had *thought* was decided should use assertions.
> 
It's a speed/safety tradeoff. Hardly any GUI calls can be perceivably (By
the user) slowed down by doing a lot of error checking. With threads, while
I would prefer that preconditions are checked I was under the impression
from the discussion that the applications that used threads couldn't afford
this extra level of safety.

Personally I use asserts in code I expect to test with a debugger running. I
use exceptions to gracefully catch errors and not blow up under the user's
face. Now I'm working on games, not heart machines. If a game crashes. Oh
well. Start again. With a heart machine I'd really rather you made a valiant
attempt to keep running and continue. (restarting/rebooting had better be
fast for this to be a viable alternative.)

On the other hand, I've had a game with a buggy resource manager cough up a
lung, paint blots of tan all over the screen, recover, and gradually paint
the screen correctly. All because I used very strict error handling (both
exceptions and return codes.) So its made me a believer in making a
reasonable attempt at error handling. I don't check for the stray particle
errors, but its reasonable that a file won't open, that the data requested
isn't there, that I couldn't send a message. Those all throw exceptions.
Null pointers handed to the draw routine should have been caught as
exceptions when the data was paged in, hence they get asserts. Range errors
that I should have limited before calling a routine are asserts. Some code
has both, an assert and a exception. In DEBUG mode I want to stop, drop into
the debugger, in RELEASE mode I want to throw. But these tend to be rare.

With the snippet that was provided, I would expect that the clipboard will
open, that I can empty it, that I set the data in the clipboard and then can
close it. Just like was pointed out, I should have enough handles to do
this. So its exceptional when it can't happen. But neither should my
released program crash if I can't perform this operation. It just makes my
software look bad.

It's a judgement call. Since you are the most expert in the threads library,
you get to make the call.

  On a side note, the better the precondition testing in DEBUG mode is, the
less complaints I hear about buggy libraries from programmers who don't
bother to read the docs. Also no matter how slow if it will run, I'll turn
all the DEBUG stuff on I can at least once near the end of the project and
see what shows up. (Or if I'm faced with a really weird bug report.) I'm
always amazed that things still run with pointers that point to random
space, counters that don't, memory that moves etc. And when I find these
bugs I always wonder how this ever worked.

  -gary-

gary.powell_at_[hidden]