cancellation points report failure

[David Abrahams]

Dave Butenhof <David.Butenhof at hp.com> writes:

> David Abrahams wrote:
>
>>Dave Butenhof <David.Butenhof at hp.com> writes:
>>  
>>
>>>Since a "phobia" is an "abnormal or illogical fear", I'd have to say
>>>you're wrong on two counts. First, I don't fear it; I merely argue
>>>that it's rarely usable and far too easy to misuse, and that the cost
>>>of the feature outweighs its value. And none of that is
>>>"illogical". Furthermore, since some of the C++ people here seem to
>>>have enough trouble with the idea of cancel as an exception in the
>>>first place, (one of those rare goals in which you and I are united),
>>>nevermind introducing the concept of an ASYNCHRONOUS exception, let's
>>>just leave this alone, eh?
>>>    
>>>
>>I, at least, have no trouble with the idea of using C++ exceptions to
>>report cancellation.  In fact, I think it's a great idea in general.
>>It's just a really bad idea for functions which can normally be
>>expected never to throw exceptions to start throwing cancellations
>>when used in a POSIX threads environment.
>>
>>IIUC, other "C++ people" who don't like the idea of printf throwing
>>an exception feel the same way.
>>  
>>
> Although I wasn't counting you in particular as an objector, I may
> have overgeneralized the objections of others. The whole matter of
> interaction with throw specs in particular is complicated, and I
> certainly don't claim to have any answers -- easy or otherwise. I've
> considered making a couple of rambling conceptual statements, but I'm
> way out of my league here on C++ philosophy and history, and I
> wouldn't want anyone to think I'm doing more than idle speculation.
>
> One of those idle thoughts was that the concept of "cancel state"
> (enable or disable) might even be meaningless (or at least
> irrelevant) for a pure C++ binding. This might simply be a dynamic
> property of the current call tree; depending on the nested throw
> specs. That is, if the cancel exception can be thrown cancel is
> "enabled"; and if it cannot then cancel is "disabled".

What do you mean by "can be", and what does it have to do with
exception-specifications?  Are you suggesting that cancellation is
disabled by writing an exception-specification that doesn't include
it?  Interesting thought, if so, but how do you disable just
cancellation without masking other exceptions?

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