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 ().
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.
----- Original Message -----
Newsgroups:
gmane.comp.lib.boost.devel
Sent: Monday, 2002:August:05 2:04
PM
Subject: Re: Re: Threads &
Exceptions
----- Original Message -----
From: "Eric Woodruff" <Eric.Woodruff@falsetto.com>
To:
<boost@lists.boost.org>
Sent:
Monday, August 05, 2002 12:33 PM
Subject: [boost] Re: Threads &
Exceptions
>Eric
Woodruff
----------------------------------------------------------------------------
----
"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
_______________________________________________
Unsubscribe &
other changes: http://lists.boost.org/mailman/listinfo.cgi/boost