Re: [boost] [Thread] Win32 exception handling

Subject: Re: [boost] [Thread] Win32 exception handling
From: Matt Gruenke (mgruenke_at_[hidden])
Date: 2008-11-26 15:05:55

David Abrahams wrote:
> on Wed Nov 26 2008, Matt Gruenke <mgruenke-AT-intellivid.com> wrote

>> THE CASE AGAINST try {} catch (...) {} IN
>> libs/thread/src/thread.cpp:thread_proxy()
>>     
>
>
> That ticket has been reincarnated at http://svn.boost.org/, as #476,
> which someone closed as fixed(!) and worse, there seems to be a bug in
> Trac that prevents the ticket from being viewed directly
> (http://trac.edgewall.org/ticket/7840).  Fortunately, you can still see the
> whole description (but none of the updates) here:
>
> https://svn.boost.org/trac/boost/query?status=closed&summary=~thread_proxy&col=id&col=summary&col=status&col=owner&col=type&col=milestone&col=version&col=reporter&order=priority&row=description
>
> Which I think matches what was was pasted here:
>   

>> A more troubling aspect of this try/catch block is that the thread
>> terminates in exactly the same way via an otherwise unhandled
>> exception as it does when the user-supplied threadfunc exits cleanly.
>> If the user of boost::thread didn't think to catch the particular
>> exception in question, then it's unlikely it employed and is
>> inspecting any other mechanism for determining whether the thread
>> accomplished its goal.  This assumption violated, it's unsafe to
>> assume the program will continue to function correctly.
>>     
>
> I disagree.  It is rare that an exception carries information that
> determines how it needs to be handled.  Usually, the same recovery
> and/or unwinding actions apply to all exceptions.
>   

I think what I meant was that an unhandled exception usually has the 
effect of leaving the program in an invalid state, either by leaving 
datastructures in an inconsistent state or simply by failing to satisfy 
other sorts of internal conditions for continued and correct operation 
of the program.  Take the example of a program which uses a dedicated 
thread for file I/O.  Even if an unhandled exception does trigger all 
the local destructors for that thread, it's likely that the rest of the 
program will still eventually block.  It would be preferable to 
terminate the program, once the exception occurs.  That at least allows 
the error to be handled at the next level (i.e. outside the process).

I think this point (i.e. that unhandled exception should *somehow* 
trigger program termination) is no longer in dispute.

>> (as opposed to relying on return codes - which facilitate errors being
>> silently ignored).  Why should behavior of uncaught exceptions in
>> other threads be any different than main? 
>>     
>
> It should not.  I think the author's assumption was that the system's
> runtime library already provided the standard-mandated call to
> terminate() when an exception escapes from main(), but since the
> standard didn't say anything about thread-termination, one can't count
> on a call to terminate() when an exception escapes from a thread.
>   

The original implementation did NOT call std::terminate().  It caught 
the exception and proceeded to terminate the thread in exactly the same 
way as if the thread function had returned.  That was one of my 
complaints, in the original RFE.  I discovered it upon investigating a 
problem in which some of my threads seemed to be prematurely exiting.

> CONCLUSION
>
> In summary, I believe the current behavior is:
>  1. Dangerous - hides program errors in a most un-exception-like
>                 manner.
>  2. Unfriendly - defeats useful debugging functionality,
>                  on some platforms.
>  3. Surprising - users don't expect libraries to inhibit propagation
>                  of their exceptions.
>  4. Unnecessary - the user can easily supply this behavior,
>   
>
> I mostly agree.  There's only the issue of ensuring calls to terminate
> when the user want CD-conforming behavior, and as Peter D. points out,
> on Win32/MSVC at least, that doesn't have to be an issue.
>   

Yeah, it sounds like my bug is only partially relevant to the current 
implementation.

Matt