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.