Re: [boost] [Boost.Thread]: consider removing catch(...) from thread_proxy

From: Slawomir Lisznianski (slisznianski_at_[hidden])
Date: 2005-08-27 07:59:32

Matt Hurd wrote:
> Yes, a user replaceable handler seems best.  Perhaps through a policy
> so a no-op could be chosen but I'm not sure if the small additional
> complexity of a policy is worth it just to allow the handler to be
> elided.

Correct me if I'm wrong, but to invoke a handler you need to catch the 
exception, right? In doing so you shall change the core file's stack 
trace, should the handler want to core. Consider:

void thread_proxy(..)
{
   try
   {
     threadfunc();
   }
   catch(...)                  <-- function that threw the except.
                                   no longer in stack trace
   {
     invoke_user_handler();    <-- aborting inside won't yield
                               <-- meaningful stack trace
   }
}

If the installed handler aborted, then we achieved the goal partially by 
eliminating silent thread deaths. Still, user has no way of knowing 
where the exception came from -- her stack trace will have: 
thread_proxy, invoke_user_handler and the handler itself. What good is 
that in diagnosing the problem?

> I'd still prefer that backward compatibility was broken and that the
> default was catastrophic failure as per a normal exception.
> The majority seem opposed to changing the default
> though, I seem to be on my own.

I would too prefer aborting program execution as well.

Slawomir