Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-13 15:30:50

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

> From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> > At Tuesday 2002/08/13 12:03, you wrote:
> > >From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> > >Is it ever useful to know what the exception type is in this case? I
> ask,
> > >because it seems to me that there's no way to recover in this case,
> the
> > >only reason for propogation is to give some possibility for a clean
> > >instead of an abrubt halt. If you can't recover, then what need is
> > >for knowing the exception type?
> >
> > Some of us plan on using boost::thread to implement separation of call
> and
> > result.
> I understand that, but unless the call is an autonomous task (i.e. it
> accesses no shared resources), then you likely can't recover, and the
> of exception doesn't matter.

I don't know why you say that you likely can't recover. If all the code is
exception-neutral and gives the basic guarantee, by the time the thread
exits, all program invariants are intact. I don't see why MT causes any
special issues here (except that rolling back shared resources is tricky at

> That said (again), I see two cases in which propogation could be useful
> explicit types:
> * The call is an autonomous task. Rare in my experience, but a very
> 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
> 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.

           David Abrahams * Boost Consulting
dave_at_[hidden] *

Boost list run by bdawes at, gregod at, cpdaniel at, john at