[boost] Re: future of boost.threads

From: Russell Hind (rhind_at_[hidden])
Date: 2004-02-10 11:35:42

David Bergman wrote:
> 
> I agree with Victor, although I might not use his hard tone ;-)
> 
> I have "only" been doing this since 1979, so I am not real old-school like
> Victor, but I must say that it seems to be better to have the system survive
> in spite of a slight programming error. Most MLOC programs have those;
> especially multi-threaded MLOCs.
> 
> There seem to be two schools here: (1) the Standardists, striving to follow
> The Standard verbatim, and (2) the Pragmatics, trying to see how different
> mechanisms would affect their daily struggles with real problems.
> 

I disagree.  The last product I worked on, we went with this approach. 
Even asserts threw exceptions which were caught, so the thread didn't 
terminate the app.  If this happened during data acquisition, we could 
still save the data.  But I see asserts as program logic error, and if 
the program isn't doing as expected, what to do you do?  Ignore it and 
allow the user to use the data?  Trust data from something that went wrong?

It can get worse: in win32, access violations get turned into exceptions 
(in Borland's VCL library, anyway), which would then just be treated as 
an unexpected exception, but it actually means something really bad has 
happened.  Should we still save the data and continue?

This may come back to the question of should errors such as access 
violations (seg faults?) etc be turned into exceptions, but IMO, 
unexpected exceptions means you don't know what happened, and therefore 
I wouldn't trust results from a run where something unexpected happened, 
and in the case of the AV, you don't know the state of the system after 
such an error so is it really safe to try and continue?

We took the approach at the time that it was (because we knew which 
thread was causing the odd problem and did trust that it didn't affect 
the data) but I don't think it should be standard practice.  We coded to 
handle unknown errors which we knew were coming in but couldn't pin them 
down.  But we did this in a specific place for a specific problem, I 
don't think it should be done as a matter of practice.

Thanks

Russell