"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.

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).

(Please ignore the boost::New<> template that I've used, that is something I will like to suggest, to work solely within the shared_ptr paradigm, without having to constantly construct them based on instance pointers returned by ::new--in my opinion, this goes beyond syntax sugar. I also develop at 1400x1050 resolution, so for those that are less fortunate, a lot of scrolling might be involved.)

----- Original Message -----

From: William E. Kempf

Newsgroups: gmane.comp.lib.boost.devel

Sent: Monday, 2002:August:05 12:59 PM

Subject: Re: Threads & Exceptions

----- Original Message -----
From: "Eric Woodruff" <Eric.Woodruff@falsetto.com>
To: "boost" <boost@lists.boost.org>
Sent: Sunday, August 04, 2002 8:56 PM
Subject: [boost] Threads & Exceptions

> I've developed a way to support user exceptions in threads that I would
like
> to contribute to boost. In my opinion, it can replace/extend (in the
literal
> sense) the existing thread class (I also think the existing manor to
provide
> platform neutrality with ifndefs is unacceptable, but that is for a new
> message thread.). At the moment I have created a boost::advanced_thread
with
> usage as simple as:

Exception handling isn't so cut and dried. You did get me to look at the
code and realize there's a bug in the implementation that I'll have to fix,
since currently we're eating all exceptions, but what should occur is as
follows:

If the thread function object throws an exception then std::terminate()
shall be called. This is compatible with the required semantics of the
"initial thread" in the standard (playing loose with terms here, since the
standard doesn't define any threads, much less the initial one, but the
terminology should be understandable and is the only translation possible in
a MT update to the standard with out causing backwards compatibility
problems). If the user requires different semantics he must employ the same
techniques as he would in a single threaded application... i.e. employ
set_terminate() or wrap the code in try/catch blocks. This means your
"advanced_thread" would be a legal extension, but it's not the appropriate
behavior out of the box.

The other addition you've made, allowing query of a "result value", is
something that's still under consideration. It's syntactic sugar since you
can achieve the same results trivially through the function object you pass
to thread creation, but sometimes syntactic sugar is worth it. The problem
here, however, is that it requires restrictions on the type (it will have to
at least be copy constructable, and likely default constructable and
assignable as well).

> boost::advanced_thread<ReturnType, OrderedTupleOfExceptions (default =
> none)>
>
> Upon access to any (most -- debatable) of the public methods of the
> advanced_thread, a user exception may be thrown. Exceptions not listed to
> the class will cause std::bad_exception to be thrown (I believe that is
> appropriate). Of course, advanced_thread<void> does not provide
> getReturnValue () {or return_value () to follow STL naming}.

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.

> For instance:
>
> #include <boost/advanced_thread.hpp>
> #include <boost/bind.hpp>
>
> int testFunction () {
>     throw 16;
>     return 11;
> }
>
> int main () {
>
>     typedef boost::advanced_thread<int, thread_exceptions<int,
std::string>
> > Thread;
>
>     try {
>         Thread testThead (boost::bind (testFunction));
>         int const returnValue = testThread.getReturnValue (); // implicit
> join
>     }
>     catch (int number) {
>         std::cout << number << " was thrown!" << std::endl;
>     }
>     catch (std::bad_exception& exception) {
>         std::cout << "An invalid exception was thrown by the thread user
> function. " << std::endl;
>     }
> }

The only real question with the above is what you'd do with the fact that
the thread threw an exception?

Bill Kempf
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost