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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-13 16:25:49

From: "David Abrahams" <dave_at_[hidden]>
> From: "William E. Kempf" <williamkempf_at_[hidden]>
> > From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> > > >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,
> and
> > the
> > > >only reason for propogation is to give some possibility for a clean
> exit
> > > >instead of an abrubt halt.  If you can't recover, then what need is
> there
> > > >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
> type
> > 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
> best).

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

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

Bill Kempf