RE: [boost] Re: Runtime error reporting

From: Jesse Jones (jejones_at_[hidden])
Date: 2001-03-20 17:20:25

> David Abrahams wrote:
>> Actually, I disagree. IMO, the stuff in assert() is very easy
>> to separate from the mainline code. Everyone must follow the rule
>> "no side-effects in assert" anyway. Adding a VERIFY() macro just
>> gives us another macro to keep track of. How does it help in any
>> substantive way?

It'd not a big win. All it does is eliminate some extra lines and possibly
some extra temporary variables. OTOH it's yet another evil macro and there
seems to be some temptation to use it where it's inappropiate.

>Taking Win32 API as an example, in theory almost every function call there
>can fail, and consistent checking for it really helps to detect induced
>errors (and their sources, of course). The problem with having only classic
>'assert'-like macro as a checking tool for such errors is that consistent
>application of "check a return value of every API function call" policy
>makes your code much more bloated and clumsy, e.g.:
>
>void clipboard::put_text(std::string const& text) {
>  HGLOBAL handle = ::GlobalAlloc( GHND, text.length() + 1 );
>  // copy text to allocated memory
>  // ..
>  // copy text to clipboard
>  bool result1 = ::OpenClipboard(0);
>  assert(result1);
>  bool result2 = ::EmptyClipboard();
>  assert(result2);
>  bool result3 = ::SetClipboardData(CF_TEXT, handle);
>  assert(result3);
>  bool result4 = ::CloseClipboard();
>  assert(result4);
>}

This is the problem with VERIFY: when it's there you're tempted to use it.
:-) The problem is that before you use it you have to think about whether
you should really be using an error code or exceptions instead. The only
time you should use VERIFY is when it doesn't make sense to throw (eg
cleanup code in a dtor) or it doesn't really matter if there is an error,
but you still want to know about it during testing (for example if your
drawing code winds up with an error throwing is dicy because you can wind
up locking the user into a infinite loop if you pop up an error alert which
causes a redraw when it's dismissed).

In the code snippet above the first three error conditions should be
handled with exceptions (or the moral equivalent). The last is a bit more
arguable, but I would probably throw: it's OK to do so there and it's
possible that CloseClipboard does something that's actually important (eg
flushing some internal buffers).

  -- Jesse