Re: [boost] [Thread] Win32 exception handling

Subject: Re: [boost] [Thread] Win32 exception handling
From: Neil Groves (neil_at_[hidden])
Date: 2008-11-25 15:13:52

Dave,

On Tue, Nov 25, 2008 at 7:57 PM, David Abrahams <dave_at_[hidden]> wrote:

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

Agreed. It seems that a debugging mode would be desirable. I appear to be in
the minority for prefering the catch(...) to be in the code so that stack
unwinding is performed and destructors are executed. Perhaps we could
implement something on Windows using imagehlp to take a snapshot of the
stack and thereby have our destructors executed and capture the stack
information?

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

Agreed.

>
> > 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 didn't think you did really! I just really want my destructors to run!

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

Of course.

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

I meant that section 15.3.9 allows the std::terminate call to occur in the
event of an unhandled exception without unwinding the call-stack, but it
also allows stack unwinding followed by std::terminate. This was also why I
asked about which standard you were asking about, since I was not sure if
you were checking compliance of the exception handling specific parts or the
threading parts. I am now though.

>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>