RE: [boost] Re: Runtime error reporting

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

>>

> I disagree. Given the calling sequence, it is guaranteed that all the
> calls
> will succeed if both the OS environment and your program are in consistent
> state (no leaked/invalid handles, no corrupted memory regions etc.). If
> they
> are not, it's a problem of a code that put your program/OS into such
> state,
> but for sure not the 'clipboard::put_text' function; assertions in that
> function only help to detect such problems early and track their sources
> more easily, but generally you better to find the real bugs instead of
> trying to live with their consequences. In any case, throwing the
> exception
> here doesn't give you anything, except that it forces all clients of the
> function to wrap the 'put_text' call into try-catch block that will be
> empty
> anyway.
<<
Then there is no point to the "VERIFY" calls either. The program will crash,
you will be running the debugger anyway so you can see that you blew it.

The problem isn't that there weren't enough handles when you tested this bit
of code, there were. Its that some maintainer added some bad code (that
doesn't release a handle), and this bit didn't get tested hard enough, Now
under some conditions, there won't be enough handles. So user's now get to
see you crash and burn. Not a pretty picture. Those bugs are what make me
work until 4am, when I'm trying to ship and QA does stress testing and my
boss says, no ship unless all crash bugs are gone, and I hate it. My kids
hate it. If the bug is "doesn't paint", "Doesn't copy to the clipboard
sometimes" I get to ship and send a patch later, maybe. (depending on the
number of complaints.) I don't have class A bugs, and during performance
reviews I don't have to explain why my project was late again.

  -gary-

gary.powell_at_[hidden]