On Thursday 06 July 2006 15:45, Peter Dimov wrote:
- try +// try { thread_param* p = static_cast<thread_param*>(param); boost::function0<void> threadfunc = p->m_threadfunc; @@ -115,12 +115,12 @@ on_thread_exit(); #endif } - catch (...) - { -#if defined(BOOST_HAS_WINTHREADS) - on_thread_exit(); -#endif - } +// catch (...) +// { +//#if defined(BOOST_HAS_WINTHREADS) +// on_thread_exit(); +//#endif +// }
This is really bad. It deactivates some code instead of removing it without the least comment why it is still there. What is the next person maintaining supposed to think? No, instead of doing this you should add a comment that says that a first approach (and an earlier version) used to catch(...) but that this effectively prevents invocation of the debugger and is therefore a bad idea. An exception coming up here is a programming mistake anyway and hiding this silently here is bad because it restricts the user's possibilities. And they can still catch(...) in their code. Also, not even catching(...), calling on_thread_exit() and rethrowing is an alternative because at that time the stack is already lost and if an exception propagates up there it would invoke std::terminate(). It thus prevents jumping into the debugger as noted above. Referring to another posting in this thread, where you try to achieve the same via a local object's destructor, there is possibly a mistake in that: AFAIK, when an exception is thrown and not caught, terminate() is invoked without(!) unwinding the stack, or am I confusing something? cheers Uli