I find the catch(...) in thread_proxy to be a real nuisance. The only thing I can do to prevent threads from silently slipping away is to put a catch(...) inside my thread procedure, but when this is hit I have no idea what the exception is or where it was thrown. I could configure the debugger (msvc71) to break whenever an exception is thrown, but then I have to wade through handled exceptions in order to find the real error. There was a discussion on this subject about eight months ago where the consensus seemed to be get rid of the catch(...)--any progress on this since then? I notice the catch(...) is still present in CVS, which isn't encouraging. As a refresher, this approach won't help... try { thread_proc(); } catch(...) { exception_filter(); // ... because I don't have a stack trace here. } This sort of approach could be okay though: if ( swallow_exceptions ) { try { thread_proc(); } catch(...) { whatever(); } } else { thread_proc(); } If swallow_exceptions were on by default, it wouldn't change behavior unless the programmer asked for it, perhaps using an optional parameter in the thread and thread_group constructors.