Boost logo

Boost Users :

From: Brian Davis (bitminer_at_[hidden])
Date: 2008-07-27 13:41:55


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.

Peter wrote:
>> 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.

Then Emil replied:
>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



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net