Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at