Boost :

williamkempf_at_[hidden]

----
"Let me see if I understand your fist sentence (since it doesn't appear to
be
illustrated by the following code).  If the user's thread throws one of the
"allowed" exceptions and some code then calls, say, boost::thread::join()
then join will throw the exception originally thrown in the thread?  That
doesn't sound usable, let alone implementable."
See my attached implementation (that had to provide some
hacking/"configuring" to get it to work with my version CodeWarrior).
There is no reason for the entire application should exit upon an exception
in a thread--that is the most un-robust soltion possible.
<Eric Woodruff
It's the only solution that's consistent with standard behavior, and it
truly causes no significant problems in usage.  If you want different
behavior simply create a wrapper class for the function objects.
boost::thread thread(my_exception_handler(&my_thread_func));
>Eric Woodruff
The only argument I can see against supporting the thread exceptions is that
the entire boost community (and I) are against exception specifications, but
as far as I can tell, it is the only way to implement them (while
abstracting the implementer of the thread function from the details
thread_throw, which otherwise makes the threaded function non-generic/thread
specific).
<Eric Woodruff
There are several points here:
* Need for consistency with the standard behavior for exception handling.
This dictates the call to terminate() for an exception that's not properly
handled.
* Need for safety.  If an unhandled exception occurs within a thread it may
well not be safe to let the process continue.  Being able to query a thread
object to see if the thread of execution was terminated by an uncaught
exception can help here, but it's error prone.  Forcing the use of normal
exception handling techniques will create the fewest misuses by the user.
Bill Kempf