"Fernando Cacciola" <fernando_cacciola@[...].com>  writes:

>  ----- Original Message -----
>  From: "Peter Dimov" <pdimov@[...].net>
>  To: "Boost mailing list" <boost@[...].org>
>  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. 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.

-- 
                       David Abrahams
   dave@[...].com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost