----- Original Message ----- From: "David Abrahams" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 7:18 PM Subject: Re: [boost] Proposed Boost Assert -- once again
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes: > > > ----- Original Message ----- > > From: "Peter Dimov" <[EMAIL PROTECTED]> > > To: "Boost mailing list" <[EMAIL PROTECTED]> > > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost