-----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