Thread Exception callbacks using boost::function boost::bind is what I have seen implemented with boost 1.34 and 1.35 due to the lack of this architecture and also a thread pool manager who received all exception callbacks. 

David wrote:
> You can throw as long as the exception will be caught before it
> propagates out of the thread function.  You can always put a
> try/catch(...) block in all your thread functions.

However an automated easily specified architecture's is desired.  Thread pool manager allowing any thread to register for thread exceptions from any thread.  This is also needed in dataflow as Stjepan and I discussed at BoostCon.  To allow dataflow components to register for exceptions in other components which can be running in other threads, but when an exception happens in the other component in the other thread the remaining components need to know about it.

Emil wrote:
> Yet to be released Boost 1.36 includes the new Exception library which
> among other things supports transporting of exceptions between
> threads.

Which is what I have seen programmers resort to in the past.  Only manually.  If this happens in 1.36 it will remove some of our code and we can take advantage of this feature.


Anthony worte:
> My futures library
> (http://www.justsoftwaresolutions.co.uk/threading/updated-implementation-of-c++-futures-3.html)
> which is on the Boost review queue provides a packaged_task which can
> be used with boost.thread to transport exceptions to the thread that
> is waiting for the result.

Sweet Anthony this may be just what I needed.  I'll check it out.

Peter wrote:
> Exceptions should be caught somewhere.
> The software engineer has to make certain of that by adding a try-catch-block on every interface boundary -- such boundaries
> are usually points where C++ borders on C or the operating system  -- e.g.
>        * the main-function,
>        * window message handlers,
>        * thread-functions,
>        * callback handlers provided by certain frameworks
>                e.g. to read from a file descriptor.

> I don't think a thread package should provide features for storing exceptions, since this would require a new base class other than std::exception.
> You may want to make certain that the exceptions thrown inside a thread function are not simply ignored -- e.g. the string returned from what() can be stored and displayed by the main thread.

Keeping the exception model to one root element is ideal, but may be idealistic.  There is other info than what std::exception can provide such as the line and file info of where the exception occurred,and the stack trace,  and what thread the exception occurred in preferably by thread name (boost threads currently to my knowledge have now way to specify a name)..  So while I too to not want exception hierarchies such as the JAVA,  I do not see how std::exception will provide my desirements (which will hopefully one day become requirements).

The key there in certain program is to keep the system running uncaught exceptions are a sure fire way to bring down a system.  Thread death with out notification of what occurred and where is another way to crash a system.

>It's even better to copy the entire exception object, not only the
>string returned from what().

I would add to this the exceptions derived children... Even though we may not want exception hierarchies, other programmers might.  So the transport mechanism should allow the full exception info supporting exception hierarchies.

Emil wrote
> I don't consider what the exception library does for STL exceptions
> very valuable. It can even be argued that it's fundamentally flawed in
> that it erases the actual exception type in case someone throws (for
> example) an exception that derives std::logic_error.

Yes a true issue.  Derived type exceptions should not be erased.

> Still, it is a reasonable workaround for the lack of language support.
> As last resort, you get an object of type boost::unknown_exception.
> This at least guarantees that no exception gets ignored.

I think Emil and I are in agreement with exception hierarchies. 

Brian