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>