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@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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>