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>