Re: [boost] Re: Re: Threads & Exceptions

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-05 13:56:18

----- Original Message -----
From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, August 05, 2002 1:18 PM
Subject: [boost] Re: Re: Threads & Exceptions

Can you please post in text mode.  My reader can't quote HTML posts, and in
general it's best to post in text mode to any public forum such as this any
way.

>Eric
William,

1. Define "not properly handled" in your first point. If the thread supports
exceptions robustly, then the exception is handled and there is no reason to
call terminate ().
<Eric

If the user doesn't catch the exception (i.e. he let's it propogate out of
the entry function) then it's not been handled "properly".  If the "thread
supports exceptions robustly", then the exception will never propogate out
of the thread entry function and thus won't cause a call to terminate().
Exceptions can't cross thread boundaries (well, theoretically they could,
but that's a completely different can of worms and most of us are convinced
that asynchronous exceptions are a very bad idea).  So the only solution
left is a polling solution, such as the one you've implemented, but polling
is error prone as there's no gaurantee the user will poll for the exception,
and thus the exception can be "lost".

>Eric
2. Nobody said the process continued when an exception by a thread was
unhandled. I stated that bad_exception was thrown, but the process still
exited. It can trivially be user defined whether to throw bad_exception or
to call terminate (). In any event, if it does throw bad_exception, and that
exception is not caught, terminate is called.
<Eric

1.  You can't just throw bad_exception here and expect anything useful to
occur.  This invokes undefined behavior as the C++ standard doesn't indicate
what should happen when an exception propogates out of a thread entry
routine, and worse, implementations don't define what should happen either
as they are C APIs.  You have two choices here, eat the exception or call
terminate().

2.  Your implementation allows specified exceptions to be thrown and
unhandled which results in the thread terminating but the process continues
on it's merry way.  This is what I was referring to.

Bill Kempf