RE: [boost] Silently ignoring errors (was Re: future of boost.thread s )

From: David Bergman (davidb_at_[hidden])
Date: 2004-02-10 15:29:30

Are there not three questions?
 
1. How do we specify what exceptions the "thread manager" should catch from
the "child" thread?
 
2. How should the "thread manager" pass those exceptions, or information
thereof, to the "parent" thread?
 
3. How should the "thread manager" handle exceptions thrown but *not*
enlisted according to (1)?
 
 
There seem to be three (I almost said "schools" - oops) points of view
regarding (1):
 
1a. no exceptions are specifically catched by the "thread manager"
 
1b. one specifes statically, using typelists etc., the types of exceptions
to catch
 
1c. one uses a dynamic scheme, as in Boost.Python, to specify the exceptions
to catch
 
Regarding (2), there are basically three ways to go:
 
2a. extract the important information of the caught exception, such as the
'what()' string, if that method exists, and pass that through either a new
exception or some regular communication channel (return value etc.)
 
2b. slice the exception into the static type, as specified by (1)
 
2c. use dynamic scheme to copy the actual exception to the "parent" thread,
such as "virtual constructor"
 
There are basically two views on 3:
 
3a. just let it be, after all, it is definitely unexpected - this leads to
the regular "unexpected" process, which usually terminates the whole process
 
3b. extract something, if possible, from the exception and inform the
"parent" thread
 
 
Most combinations are valid.
 
The hard-core attitude would be 1a + 2a + 3a, i.e., do not enforce a layer
of protection to the thread library user, if he wants that, he would use
Java, or even VB ;-) 
 
The lenient, and all-too-safe(?), attitude would be 1b + 2b + 3b.
 
I would suggest a static scheme, but to let through unspecified exceptions
to do their "unexpected" dance. I.e., 1b + 2b + 3a.
 
/David

  _____  

From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Rob Lievaart
Sent: Tuesday, February 10, 2004 2:13 PM
To: 'Boost mailing list'
Subject: [boost] Silently ignoring errors (was Re: future of boost.thread s
)

The discussion drifted away from "should we be able to pass exceptions 
from one thread to another" to a more general topic of what to in case 
of unexpected errors.  I'd like to put in my $0.02 cents here.  

While there are cases where the best solution to unexpected errors, 
is restart a thread, ignore part of the results and pray.  
I think they are not that common and require explicit programmer 
action to decide when to pray and when to really give up and abort 
the program.  

Catching and silently ignoring an error by default is IMHO the worst 
possible choice.  It should be possible for a programmer to ignore 
a lot of errors if he wants to, even acces violations in some cases, but 
I think the default behavior should be for the system to "scream" as 
as loud as possible if something unexpected happens. 

So coming back to the boost.threads discussion, if the default behavior 
for unexpected exceptions was to dump core, or jump into the debugger that 
seems like a pretty loud scream. (As several others allready pointed out 
the more information you get in a situation like this the better) 
When I need other behavior, it should be a conscious decission on my part 
to handle these unexpected situations, and then they are not really 
unexpected anymore. 

Kind regards, 

Rob Lievaart. 

<war story> 
The first example that comes to mind is a system where I spent a week and 
a half looking for a bug (After several others had tried to find it 
before me an failed) that had been in the system for wel over a year. 
The bug caused _allways_ caused an error in the program that was silently 
ignored. The program worked "perfectly", for a while, untill the harddisks 
became larger and the amount of free space on customers computer 
increased.  Then it started giving loads of problems.  If this error 
had not been silently ignored, the bug would have been spotted during 
the first test after it was introduced, and it probably would never 
have been checked in into the revision control system. 
</ware story>