Dave, On Tue, Nov 25, 2008 at 6:05 PM, David Abrahams <dave@boostpro.com> wrote:
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. 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.
The catch clause in the code is a good thing in my opinion because of 15.3.9 in the standard which states: "If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined" I typically want my destructors to run, so I prefer to have this catch block present. The alternative is to implement catch (...) in all functions run by thread. The disadvantage is, of course, that debugging is more awkward after an unhandled exception. When using Visual Studio I have found it useful to configure the exceptions to stop when thrown, although this might prove impractical for some. Due to the my perceived necessity to guarantee stack unwinding, I propose that "leaking" the exception is ok if by "leaking" we mean to optionally rethrow.
I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea?
Do you mean conforming to the current C++ standard or to a newer thread proposal? I believe that section 15.3.9 means that either order of stack unwinding and termination is allowable.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Neil Groves