Feature Requests item #1274707, was opened at 2005-08-27 14:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1274707&group_id=7586 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: thread Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: William E. Kempf (bill_kempf) Summary: Remove try/catch(...) in thread.cpp:thread_proxy() Initial Comment: THE CASE AGAINST try {} catch (...) {} IN libs/thread/src/thread.cpp:thread_proxy() The only platform on which I've used boost::thread is Linux + GCC. So, on the debugging front, I can only speak to that. In this configuration (using pthreads), the behavior of an exception being allowed to propagate outside of a thread function is quite useful - you get a backtrace of the entire call sequence leading up to the throw, AND a full unwind back from that point (which looks like further entries in the call stack). However, if an exception is caught & rethrown, all of the prior call & unwind history is lost. Obviously, this also happens if an exception is caught and not rethrown - which is the current (circa version 1.33.0) behavior of thread_proxy(). I've tried a number of experiments, as well as inspecting pthreads & glibc code, and have been unsuccessful at reproducing this behavior in user code. However it's so useful that, on virtually every project where I'd like to use boost::thread, I eventually resort patching the source to remove this last-resort try/catch block. For a library to be of much practical value, debugging must not be significantly impaired (and even enhanced, where possible without significant compromises). The additional complexity of multithreaded programs makes this all the more important. I think this point stands pretty well, on its own. 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. Since the thread exists in the same memory space as the rest of the process (and shares library state, if not also other data structures), an unhandled exception indicates bad state in the process, or some other invalidated assumption. In fact, in non-exception-safe code, it may even produce bad state. Any of these conditions makes it unsafe to assume the program will continue to operate correctly. Finally, there's a more philosophical point that should probably be made. The primary purpose of exceptions is to provide proactive notification of program errors (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? Yet thread_proxy() just quietly drops them on the floor. As a user, I normally expect that no unhandled exceptions were thrown, if my program runs to completion. WHAT WILL HAPPEN IF IT'S REMOVED? If the user specifically wants this behavior, it can suitably augment its user-supplied threadfunc to contain the catchall. There's nothing wrong with simply stating that the behavior of exceptions that propagate outside threadfunc is undefined. While changing this might "break" some existing code, it's really quite likely that code is already broken - though the user simply doesn't know it. IMO, there's nothing wrong with libraries evolving to detect more errors and invalid conditions. 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, if desired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1274707&group_id=7586 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs