[boost] Re: Re: Threads & Exceptions

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-05 13:18:58

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 ----- 
  From: William E. Kempf 
  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_at_[hidden]>
  To: <boost_at_[hidden]>
  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