Boost logo

Boost :

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:


>After having read:
>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

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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at