From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2004-02-10 10:55:37
On Tue, 10 Feb 2004 15:59:35 +0200, Peter Dimov <pdimov_at_[hidden]> wrote:
> 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".
I think it all depends on the context. If you are doing multithreading in
the traditional sense then yes, propogating the exception is odd.
But another type of multithreading is one which Boost.Threads encourages,
and that is calling a function synchronously to the main thread of
execution.
It seems only a logical progression to allow the user access to the return
value of the called function, and you can't do that (IMO) without
propogating an exception of some sort in the situation where there is no
resurn value. Why not give the user the option of how an exception is
propagated. It won't hurt the purists at all because they can easily
carry on using boost::thread which will not propagate exceptions.
This is something I've often emulated by passing reference's to thread
functions, and I would find a helper to do this useful in the real world
frequently.
That said, I don't think that boost::thread should be changed to add this
capability, boost::thread implies the traditional type of multithreading
to me. I've implemented a class async_call that does basically what
Victor suggested, implemented as a wrapper around boost::thread.
Use :
int f();
try
{
async_call<int [, my_exception [, ...]]> async_f(f);
int x = async_f.result();
}
catch (my_exception e)
{
// ...
}
NOTE: In the event of an exception not listed being thrown by the thread
function, std::bad_exception is currently thrown, I'm not sure if that is
ideal behaviour or not.
Sam