Re: [boost] Re:Re:Re:Re:Re:Re:AttemptingresolutionofThreads&ExceptionsIssue

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-13 16:12:03

From: "William E. Kempf" <williamkempf_at_[hidden]>

> Because when we propogate an exception "automatically" we have no way of
> knowing in the other thread whether or not the code actually was
> exception-neutral and gives the basic gaurantee.

Exception-neutrality actually doesn't matter. The basic guarantee is a
reasonable base assumption. It's the same requirement that the standard
places on UDTs manipulated by the standard library.

> This is what I tried to
> point out in the second use case below (though I glossed over the fact
that
> there's ways to ensure this, i.e. the RAII mechanism, that don't actually
> catch the exception).  I suppose we can document that the thread must
insure
> this is the case, but then I'd expect people to question why exception
> propogation is being employed since that makes it more difficult to catch
> such programmer errors during QA.

I don't undertstand the above, but I'm not sure I need to...

> > > That said (again), I see two cases in which propogation could be
useful
> > with
> > > explicit types:
> > >
> > > * The call is an autonomous task.  Rare in my experience, but a very
> > valid
> > > use case.
> > > * The exception *was* properly handled within the thread (i.e. shared
> > > resources are gauranteed to be in a valid and expected state) but you
> > wish
> > > to "rethrow" the exception so that it propogates to the calling
thread.
> > > Also a valid use case, though I'd expect this idea will lead to many
> > > programmatic errors.
> > >
> > > Like Mr. Abrahams, I question whether or not we can implement this,
> >
> > I don't think that's quite my position. I think it's implementable, but
it
> > comes with a significant pile of limitations which people should be
aware
> > of, and which might even make it not worth implementing.
>
> OK, sorry for the misunderstanding.  I guess I don't see how it could be
> implemented.  Everything I can think of will lead to sliced objects in at
> least some circumstances, making the utility very limited.  Maybe that's
> what you mean by it not being worth implementing?

Yes.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com