|
Boost : |
Subject: Re: [boost] [Thread] Win32 exception handling
From: Neil Groves (neil_at_[hidden])
Date: 2008-11-25 13:18:38
Dave,
On Tue, Nov 25, 2008 at 6:05 PM, David Abrahams <dave_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk