Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-18 14:46:05


--- 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.

Bill Kempf


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