Re: [boost] [Thread] Win32 exception handling

Subject: Re: [boost] [Thread] Win32 exception handling
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-25 14:57:42

on Tue Nov 25 2008, "Neil Groves" <neil-AT-grovescomputing.com> wrote:

> 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"

Well, good or not, that makes it required if we want to conform to the
upcoming standard.  A leaked exception under Win32/MSVC does not cause
terminate() to be called.  However, it might be good to provide a
non-conforming mode for this purpose.

>
> 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.

That's fine when you're running under the debugger, but if you want good
post-mortem information and/or JIT debugging, you need to leak the
exception or use the set_se_handler trick, which -- I think -- only
helps for segfaults and the like, not C++ exceptions.

> 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.

That's not what I meant.

>> 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? 

There's no threading in the current standard; I meant the CD.

> I believe that section 15.3.9 means that either order of stack
> unwinding and termination is allowable.

I don't know what you mean by that.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com