|
Boost : |
From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-08-14 08:04:30
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk