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>