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