-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
The "whether" part is that we (arguably) need the ability to specify a
Brock Peabody wrote: list
of "expected" exception base classes at thread creation time. I'm still not sure about that, since this is for all intents and purposes an exception specification. Much the same effect can be achieved by just decorating the thread function with one.
With a global register and no expected exception list, won't it be possible for changes in one part of the program to affect which exceptions are propagated into the calling thread in another part of the program? Is that good or bad?
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. This is particularly relevant when you control the throw point and the catch point, but not what is between them; one simple example is when you pass a throwing function to std::for_each. 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.
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. :-)