Re: [boost] Re: future of boost.threads

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-02-10 08:59:35

Alexander Terekhov wrote:
> David Abrahams wrote:
> [...]
>>> 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?
>
> I'm convinced that propagating *unexpected* exceptions into the
> joining thread is totally wrong and insensible.

Maybe, for some meaning of "unexpected".

One case where "propagating" exceptions is wrong is when the thread is not
supposed to be joined. Since exception propagation is done on join(), the
end result would be threads dying silently on an uncaught exception. This
has already been proven to be a problem in practice; hence, the default
behavior should be to terminate() when an exception escapes from the thread
function.

The other case where propagation would be wrong is when the thread has been
terminated by an exception that indicates a programming error. On the
surface, this implies that we need a mechanism to label some exceptions
"call terminate()" (or equivalently, label some exceptions "propagate" and
call terminate() on the rest.)

However, we already have such a mechanism. It is called "exception
specification". I see no good reason to duplicate it on a library level.