[boost] Re: Threads & Exceptions

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-05 12:33:17

"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_at_[hidden]>
  To: "boost" <boost_at_[hidden]>
  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