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

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-27 11:36:33

"Slawomir Lisznianski" <slisznianski_at_[hidden]> writes:

> On Fri, 26 Aug 2005 09:18:25 -0400, "David Abrahams"
> <dave_at_[hidden]> said:
>> 
>> What's expected doesn't matter.  It's what's implemented that counts.
>
> I think, in the context of this discussion, 

Let's just restore that context, shall we?

You wrote:

> Althought no standard mandates it, it is commonly expected that each
> thread can set its own terminate() or unexpected() function -- calling
> set_terminate() or set_unexpected() in one thread affects only the
> exceptions in that thread.

> it matters quite a lot. What we are debating specifically, is
> whether a library can allow for customization, yet leave an option
> of having a default (usually commonly expected) behavior of coring
> with a full stack trace.

My point was that it doesn't matter if people expect that capability
when the compiler and/or OS don't provide it.  Arguments about what is
"usually commonly expected" are almost always a reflection of the
expectation of the person making the argument, and not based on any
kind of hard data.  Is this case an exception?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com