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