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