RE: [boost] Re: future of boost.threads (implementation)

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2004-02-11 14:26:27

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of David Abrahams

> >> Generally if you have a bunch of interacting libraries it makes sense
> >> for each one to be able to register its exception
> >> serializers/deserializers/translators or whatever.  Why should the
> >> thread invoker have to enumerate the possibilities each time?
> >
> > The invoker could store often used lists in typedefs.  They could easily
> add
> > or remove exceptions from these.
> 
> That doesn't sound like ease-of-use to me.

Just to prove to myself that I could do it I implemented a rough version of
what I was talking about.  I think the interface is pretty easy to use.  

   exception_transporter.h - non thread related tool for transporting 
      exceptions in a typelist.  Could be used for other areas where 
      exceptions    propagation is an issue.  Returns exceptions in a
      variant so the user can    inspect or throw them.

   thread_with_exceptions.h - used like:

      thread_with_exceptions<exception_type_list, return_type>
         t(thread_function);

         //may propagate an exception from the list
      return_type rval = t.join();

   main.cpp - implements a small example.

Does this seem like a reasonable approximation of what people have been
asking for?

I think there needs to be a way to say "catch all exceptions derived from X
and transport them as Y, using F to construct the Y's".  Like "catch all
exceptions derived fro std::exception and transport them as
std::runtime_error by passing what() to std::runtime_error's constructor".