Boost logo

Boost :

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2004-02-12 13:28:19


> -----Original Message-----
> On Behalf Of Peter Dimov

> It can be both good and bad, depending on... I could say "the design", but
> it mostly depends on the design philosophy. I think that it's neutral, and
> just mirrors how exceptions work when threads are not part of the
> equation.
> Clearly, changes of parts of the program can affect which exception is
> propagated to other parts of the program. As long as the other parts are
> not
> hardwired to expect a particular kind of failure, all will be fine and
> well.

That's true. I'm still a little uncomfortable with the idea of a static
register though. How, for instance, would you share a register between
dynamic link libraries if the register is static?

> The main danger I see is not when join() throws an "unexpected" exception,
> but when join() is not called at all. This is bad; without threads an
> exception annoys functions up the call stack until someone accepts the
> responsibility to handle it, but without a join(), the thread exception
> will
> be lost silently. I'm not sure how this can be fixed; calling terminate()
> when the last reference to the thread goes away seems rather drastic, but
> may prove necessary.

I think it would be better than a silent failure.

> > If there is an excepted exception list, do you think it makes sense
> > to have the library automatically register the types in this list?
>
> Possibly, but I'm not sure how useful that would be. I'd usually only put
> abstract base classes in that list. :-)

Now I'm confused again :) My understanding was that there is no way to
transport a user defined abstract base class unless you derive it from
transportable_exception, in which case it wouldn't need to be registered at
all.

My list would almost always be either just std::exception - so I could
log/report what happened before terminating - and/or some concrete base that
I don't mind slicing.

Brock


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk