Some compilers (certainly GCC) have the ability to preserve the stackframe from the time it was thrown (!), for uncaught exceptions. If you catch (...), then the destructors of all the locals will execute and you'll lose some information that could be instrumental in tracking down the cause of the exception. For that reason, among others, it's good to avoid the catch/rethrow construct. The catch (...) is one of the reasons we don't use boost::thread. I even filed a bug on it: http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586 Matt Chris Newbold wrote:
From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of David Abrahams
I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions.
Are you referring specifically to the catch(...) in thread_start_function?
They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate.
Doesn't the call to std::terminate() from that catch(...) block result in the application dying in a manner which allows the debugger to intervene?
-Chris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost