Matt, On Tue, Nov 25, 2008 at 7:01 PM, Matt Gruenke <mgruenke@intellivid.com>wrote:
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.
Your point is completely valid, but because 15.3.9 allows the stack to not be unwound this might mean that destructors do not run that would release resources do not get cleaned up by process termination. Hence there are valid reasons to do both. I expect this is why the standard explicitly allows both arrangements.
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
I suppose the only sensible solution is to allow both solutions in boost.thread too. Neil Groves
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost