Boost logo

Boost :

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-18 15:46:58


--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > From: "terekhov" <terekhov_at_d...>
> > > --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > > [...]
> > > Mr. Butenhoff agreed with our decisions on N4
> > >
> > > Where can I find this newspaper, Bill?
> > >
> > > http://groups.google.com/groups?as_umsgid=kZ7h7.623%24bB1.30401%
> > > 40news.cpqcorp.net
> >
> > Great link.
> >
> > > "> My second question is whether the C++ catch(...),
> > > > which means "catch all exceptions", should be
> > > > allowed to catch the pthread cancelation exception.
> > > > On Tru64 Unix, catch(...) does catch pthread
> > > > cancelations.
> > >
> > > Yes, it should; but you should always re-"throw"
> > > unless you're really sure you want to break the
> > > entire world. I think that should ALWAYS be true
> > > for an anonymous catch(...), though. If you don't
> > > know what it is, you can't "finalize" the exception
> > > recovery, and you need to just clean up your own
> > > local context and let someone else further down
> > > handle it.
> >
> > Something that I've been trying to say from the start.
> Cancellation/thread
> > exit is a C++ exception. Everything else simply falls out from
> general C++
> > exception handling principles. catch(...) blocks should nearly
> always
> > rethrow not because of thread cancellation, but because this is
> usually the
> > right way to handle exceptions.
>
> I think for the most part we are all in violent agreement. I guess
> we keep going in circles, though, because some people think it's
> important to emphasize the "nearly always" and "usually" in your
> above statement. All of this is precisely why I had N7 in the
list.
> I agree with you that "general C++ exception handling principles"
> already cover this, but I still think it's important to re-
emphasize
> it any way.

Personally, I just want to know for sure whether on exit
from e.g. catch(cancel_e) { /* cancel.points */ } non-
re-throwing (or just throwing something else) handler we
are supposed to have cancellation re-enabled (N5 aside).
If YES, then please explain WHY, and if possible, with
some example(s). Thank you!

<another message>

> You yourself have been arguing for N4

Umm.. Are you sure? Well, if I did something like this
(cancel/exit eating is OK), then why would I ever think
of something along the lines of auto_rethrow_exception?
Hmm.. Do you have a link?

regards,
alexander.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk