Re: [boost] Attempting resolution of Threads & Exceptions Issue

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-12 16:08:28

From: "William E. Kempf" <williamkempf_at_[hidden]>
> >
> > Sorry. I don't follow the connection. It is true that exceptions when
> > handled incorrectly can cause race conditions, deadlocks, and resource
> > leaks; but I don't see how exception propagation (or lack thereof)
affects
> > this problem.
>
> It leads to a false impression that the exception handling has been fully
> encapsulated and there's little the user has to do but wrap join() in a
> try/catch.  That's why I think the functionality may indeed be useful at
> this library level, but only as a non-default option, to eliminate the
> incorrect perception and force the programmer to think about what he's
doing
> (but at the same time making the exception passing uniform and easy).
>
> > > Of these, probably half or more could benefit from returning a
> > > value as well.
> >
> > Perhaps, so I guess you are concerned about programmers (ab)using
> thread<R>
> > just for the return value, without taking into account how this affects
> > exceptions? The only real danger is using thread<R> but never checking
the
> > return value with join(), and losing the exception.
>
> Or in not handling exceptions appropriately in the areas where multiple
> threads interact together!  That's the greater danger in my mind.

I am still left with the impression that I'm missing something. Could you
illustrate this with an example? A program where moving to exception
propagation causes exception-related problems.