RE: [boost] std::exception -- Re: Re: Re: Re: Re: Attempting resolutionofThreads&ExceptionsIssue

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-14 12:03:48

True,

It would be similar to throwing a new, say
boost::foreign_thread_exception, with nested information (like the
original what()). This is what is often done in RPC-scenarios, such as
CORBA and RMI ("hey, where does this Java guy come from? Get him out of
here!"), where you have RemoteException.

Maybe it is time everyone acknowledge the fact that this thread-crossing
scenario is actually quite like the RPC scenario, where we do not have
direct access to original structures. So, let's throw that
boost::foreign_thread_exception...

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Anthony Williams
Sent: Wednesday, August 14, 2002 9:05 AM
To: boost_at_[hidden]
Subject: Re: [boost] std::exception -- Re: Re: Re: Re: Re: Attempting
resolutionofThreads&ExceptionsIssue

Eric D Crahen writes:
 > // Just a rough outline of how it might be used with a library
 > // like ImageMagik++ (http://www.imagemagick.org). It incomplete,
 > // I'm just trying to show one kind of use.
 > 
 > ImageFutue f("somefile"); // Start loading an image in another thread
 > using
 >                           // Image.read()
 > 
 > // ..                     // Do some other things for a while, setup
the
 >                           // frame to display it, find the matching
 >                           // thumbnail that won't take as long to
 >                           // load image, whatever
 > 
 > try {
 > 
 >   Image& img = f.getImage(); // Get the ImageFuture threads result.
 > 
 >   // paint it, print it, etc
 > 
 > } catch(ErrorCorruptImage&) { // not derived from std::exception
 >   // ... Handle one error one way
 > } catch(ErrorFileOpen&) {     // not derived from std::exception
 >   // ... Handle the other error another
 > }
 > 
 > This particular library has its own exception hierarchy, alot of
libraries
 > do (off the top of my head, CORBA ORBs are another that come to
mind). If
 > the thread is able to propogate exceptions automagically from one
thread
 > to another, it works out very nicely; using the thread based future
or
 > using something else like it becomes simpler (from the ImageFuture
users
 > point of view). Its easier to replace the Future class with one that
 > isn't based on a thread if you need to. It also makes it easier to
 > introduce some thread use into a program that already handles the
 > exceptions that existing functions (like Image.read()) might throw.
If
 > you only have the ability to use std::exception based exceptions, it
 > makes it more difficult to use threads in this way with libraries
that
 > don't use std::exception.

In this case, the threading is an internal detail of ImageFuture, and
you (the
author of ImageFuture) know what kind of exceptions you wish to
propagate out.
Therefore, you can catch those in your thread function, and provide
special
handling. This is independent of any general exception-propagation
method.

In general, it is not possible to propagate arbitrary exceptions across
thread
boundaries, since (a) you don't know what type they are, and (b) even if
they
are derived from a known type (such as std::exception), you don't know
what
type they are. Unless they derive from a known type, with a virtual
clone()
mechanism, it is not going to be possible to correctly copy the full
state of
the exception, and the best that can be done is to pass across
std::exception.what(), or similar. Of course, you could write a template
to
propagate a given list of exceptions (slicing any derived exceptions),
but
this still requires up-front knowledge of what types to allow.

Anthony

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