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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-02-12 11:56:59

Brock Peabody wrote:
>> -----Original Message-----
>> From: boost-bounces_at_[hidden]
>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Peter Dimov
>>
>> The "whether" part is that we (arguably) need the ability to specify a
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. :-)