Re: [boost] Proposed Boost Assert -- once again

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-14 18:03:44

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, November 14, 2002 7:18 PM
Subject: Re: [boost] Proposed Boost Assert -- once again

> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
>
> > ----- Original Message -----
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> > To: "Boost mailing list" <boost_at_[hidden]>
> > Sent: Thursday, November 14, 2002 1:32 PM
> > Subject: Re: [boost] Proposed Boost Assert -- once again
> >
> >
> >> - there is no explicit support for throwing exceptions, and no standard
> >> exception class is defined. (Although it is trivial to define a handler
> > that
> >> throws.) This is intentional. I don't believe that we, at Boost, want
to
> >> encourage this particular programming practice (assertions that throw.)
> >>
> > AFAIK, the differences between abort and throw are two-fold.
> >
> > On one hand, there are platform/compiler-dependent differences.
> > Some enviroments (mostly Unix-like) don't allow you to get context
> > information at the point of the throw, but, OTOH, supply a core-dump in
the
> > case of abort(). On these enviroments, abort() is clearly superior.
> > Other enviroments (Windows) do allow you to get context information at
the
> > point of the throw and do not supply a *textual* core-dump for
post-morten
> > debugging (although you can use JIT). On this enviroment, throw is
clearly
> > superior.
>
> Strong disagreement!  Regular exception handling constructs can
> interfere with your ability to do post-mortem debugging if you assert
> by throwing an exception.

OK. I accept that exceptions are only viable IIF the debugger can stop right
after it is thrown; unless you need to application to keep running which is
really an application-level problem, not library-level.

>That makes asm { int 3 } or the equivalent
> (which is what most of the built-in asserts do) much better on Windows
> for assertions. Regular exception-handling constructs can also
> interfere with asm{int 3}, but fortunately it's fairly easy to prevent
> that in most cases. See libs/python/test/module_tail.cpp for the
> trick.
>
Oh yes, the good old DebugBreak() which is available in the Windows API. I
forgot about it.

All right, Borland's assert calls abort() unfortunately, which makes it
pretty useless; but the DebugBreak() trick is really good! I like it.

So I would settle for this 'trap into debugger' trick for assertion
behavior. No exceptions.

Fernando Cacciola