Re: [boost] Re: Re: Threads & Exceptions

From: Dale Peakall (dale.peakall_at_[hidden])
Date: 2002-08-08 08:03:40

On Thursday 08 August 2002 12:10 pm, you wrote:
> From: "Dale Peakall" <dale.peakall_at_[hidden]>
> > On Wednesday 07 August 2002 4:54 pm, you wrote:
> > > I think so.  Which is only evidence that the logic applied isn't
> > > necessarily the logic that everyone would apply, and thus the premise
> > > (that thread<void> would indicate nothrow semantics) is shaky at best.
> >
> > I have to agree with Bill here.  It just doesn't fit in my view of
> > "common sense" which means that as I'm clearly not alone it can't be
> > considered as entirely "obvious" semantics.  To be honest, it looks,
> > smells and feels like a hack :-)
>
> I am not claiming that it is "obvious". I said that it is "logical", in the
> sense that when you see the explanation, you smile and think "So there _is_
> some twisted logic in that!" :-)

I'm glad we agree that it's not obvious, and with the help of your example I 
can see how you might consider it logical, but I still don't believe that 
it's right.  Things should behave consistently.  

Why should I allow exceptions to escape from a thread that returns a value, 
but not from a thread that doesn't?

> > If you don't want your worker threads to cause your application to
> > terminate on unexpected exceptions catch(...) and add whatever logic is 
> > appropriate to your application.
>
> No, I don't want my application to terminate on _expected_ exceptions
> thrown by the worker threads.
>
> double f(double x);
>
> double r;
>
> try
> {
>     r = f(1.0) + f(2.0) + f(3.0);
> }
> catch(domain_error)
> {
> // ...
> }
>
> I want to be able to transform this to:
>
> thread<double> tf1(bind(f, 1.0));
> thread<double> tf2(bind(f, 2.0));
> thread<double> tf3(bind(f, 3.0));
>
> try
> {
>     r = tf1.join() + tf2.join() + tf3.join();
> }
> catch(domain_error)
> {
> // ...
> }

OK, I can finally see why you might want an exception to escape from your 
thread, and I can see why its "logical" to want this specifically when 
dealing with threads that return values.  But as stated above, I prefer 
consistency over "twistic logic".

My thread-usage generally involve long-lived threads that are only joined as 
part of tidy system shutdown and as I've stated I want my application to 
terminate on uncaught exceptions in the thread as they always indicate an 
error.  Perhaps those of us who want this behaviour should use catch(...) and 
call terminate.

        - Dale.