Re: [boost] [Boost.Thread]: consider removing catch(...) from thread_proxy

From: Matt Gruenke (mgruenke_at_[hidden])
Date: 2005-08-30 18:52:59

(Sorry for quoting so much of the original message, but I felt all of 
this context was necessary for the fairest and most comprehensible reply.)

Roland Schwarz wrote:

<snip>

>After having read:
>http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7586&atid=357586
>
>And the summary there:
>
>  
>
>>In summary, I believe the current behavior is:
>>1. Dangerous - hides program errors in a most
>>un-exception-like manner.
>>    
>>
>
>I don't think so. Please explain why errors could be hidden.
>  
>

You don't see why I consider silently swallowing unhandled exceptions to 
be effectively hiding program errors?  I'll try my best to support that 
claim, but I think we may have encountered a fundamental difference of 
opinions.

>>2. Unfriendly - defeats useful debugging functionality,
>>on some platforms.
>>    
>>
>
>I understand this, and agree.
>
>  
>
>>3. Surprising - users don't expect libraries to inhibit
>>propagation of their exceptions.
>>    
>>
>
>I can see this only in the light of 2) since the only target
>where the exception could be propagated to,
> is the debugger.
>  
>

<snip>

>Since the catch all only is effective on windows and only
>guards against memory leakage in a case where the program
>is in questionable state anyways (uncaught exception), I would
>restate my recommendation to remove the catch clause
>entirely.
>
>I think the debuuger argument is much stronger than the
>safe-guarding against memory leakage in this case.
>  
>

Actually, I see no case for worrying about resource deallocation, here.  
To me, it's not much different than installing a handler for SIGSEGV 
(the signal UNIX processes receive when they try to access memory 
outside of their address space), to do the same thing.  The only 
reasonable thing to do, besides exit & let the OS reclaim your 
resources, is try to perform some action (logging, etc.) to aid with 
postmortem analysis (which users of boost::thread can do, by a number of 
means, in cases where dropping into an interactive debugger or 
collecting a core file aren't options).

I equate a memory access violation with allowing an exception to 
propagate outside of a user's threadfunc, because both generally 
represent a violated assumption.  The key difference is that exceptions 
provide a more flexible mechanism for the addressing the problem at 
higher levels (that, and the problem that triggered the exception is 
more likely to be a problem that can be addressed).  If the exception is 
never caught, then you can't assume the underlying problem was ever 
addressed - you can assume only that the process may be in an unknown, 
bad state.  Given that the problem may not have been addressed, you 
can't assume the program can continue to operate correctly.  Whether the 
exception was triggered by bad state or simply by receiving 
bad/unknown/unhandled input, it seems like the right thing to do is to 
inform the user that the program failed to behave as 
expected/requested.  In other words, simply continue to defer the error 
to the next higher level - the user (or whatever higher level entity 
invoked the program - be it a script, another program, an OS facility, 
etc.).  I regard this as a logical extension of normal exception behavior.

To approach it from another perspective, ask 100 C++ programmers the 
question: "What happens when an unhandled exception is thrown?"  I'm 
willing to bet that the vast majority will say "abnormal program 
termination", without even considering that the thread triggering the 
throw might be relevant.

Given this assumption about exception behavior, if my program exits 
cleanly, I'm going to assume that no unhandled exceptions were thrown 
(i.e. no detectable errors occurred which trigger an exception to be 
thrown that I don't handle).  For most of us, this is a useful 
approximation of correct operation (i.e. though a clean exit doesn't 
exactly tell me what did happen, it does tell me what didn't happen - 
any of the various unhandled errors I judged probable enough to bother 
checking for).

Since it deviates from exception behavior in the main program thread, I 
see this aspect of boost::thread's behavior surprising (meaning it 
violates fundamental & I think reasonable assumptions programmers 
make).  Since systems behaving in an unanticipated manner is a common 
source of design & operator error, I believe this also makes it dangerous.

As always, I appreciate the opportunity to discuss these issues.  I will 
try to continue to participate, so long as the discussion remains 
productive (i.e. as long as I feel I can contribute new information and 
views, on the matter).  That said, it seems both sides of the matter 
have been pretty thoroughly articulated.

Matt Gruenke
Software Engineer
IntelliVid Corp.