Boost logo

Boost :

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-02-09 17:56:43

> On Behalf Of David Abrahams
> Subject: [boost] Re: future of boost.threads
> Stefan Seefeld <seefeld_at_[hidden]> writes:
> > Glen Knowles wrote:
> >> From: David Abrahams [mailto:dave_at_[hidden]]
> >> >> Of course you cannot portably pass all exceptions, but you may
> able
> >> >> to pass all the ones that use standard types.
> >> >
> >> >And what if the std library or somebody else throws exceptions
> >> >*derived* from the standard types?
> >> If it is not a recognized corba exception what the ACE TAO does is
> >> eat it with a catch(...) and then throws a corba system exception
> >> the other side.
> >
> >
> > yes, so all exceptions that are allowed to pass have to be
> > declared
> > as such. If it is not declared, a special standard exception will be
> > thrown (or may be something equivalent to 'unexpected'). If it is
> > derived from a declared one, it will be sliced.
> Is everyone convinced that propagating the exception into the joining
> thread is the right behavior or even semantically sensible?

No. I'm not. Though I do think it makes sense sometimes. Other times,
(perhaps most other times for my code??), I think normal unhandled
exception behaviour is appropriate.

For example, if I have a pool of worker threads it makes no sense to me
to have the unhandled exception propagate back. What happens to the
other threads happily chewing through work? It should be the
responsibility of the worker pool to handle this appropriately.

If it was a simple single thread work off load or perhaps a block
waiting thread then exception propagation may make sense to me. That
is, if I have someone waiting to join() me.

What happens if no one wants to join() the fun, where does your
exception go? Sometimes a thread might just do its work and shutdown or
some such, the semantics of your app might not require a join(). It
might be an asynch messaging passing app where program life time is
determined by shutdown messages propagating through or some such.

I think support for propagating exceptions to support particular use
cases and idioms makes sense, but I don't see it as a safe thing for
all. Default behaviour should be to blow up and cause the chaos you've
asked for within your design. You should have to ask for propagation
explicitly where appropriate.

I am also completely and utterly convinced that I am fairly ignorant of
these matters ;-)


Matt Hurd

Susquehanna Pacific P/L

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Boost list run by bdawes at, gregod at, cpdaniel at, john at