On 8/7/07 8:19 PM, in article rm4ui.82439$%k.225146@twister2.libero.it,
"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> wrote:

> Eric Niebler ha scritto:
>>
>>   bool uncaught_exception() throw();
>>
>>   Returns: true after completing evaluation of a
>>   throw-expression until either completing
>>   initialization of the exception-declaration in
>>   the matching handler or entering unexpected()
>>   due to the throw; or after entering terminate()
>>   for any reason other than an explicit call to
>>   terminate().
>>
>>
>> I can read this two ways:
>>
>> 1) Returns true after <blah> or after entering terminate() ...
>> 2) Returns true after <blah> until either ... or after entering
>> terminate() ...
>>
>> If I choose the second reading, the program should print "HERE". If I
>> choose the first, it shouldn't. What is the intention?
>
> FWIW, I believe the intent is the first one, for two reasons:
>
> 1) the semicolon is a strong suggestion that the second "or..." is not
> related with the preceding "either... or..." construct, but rather an
> alternative to the entire phrase starting with "after completing...". If
> it was meant the other way, then there would be no semicolon.

No, the entire paragraph defines transitions: the transition of
uncaught_exception()'s return value to a "true" state and its transitions
from a "true" state to a "false" state. Clearly, the only way for
uncaught_exception() to enter a "true" state is for the program to throw an
exception (after all, nothing can be "uncaught" until something has been
thrown). So there is only one transition to a "true" state described in this
paragraph, meaning that the other three transitions mentioned must be
transitions in the opposite direction (that is, true-to-false) or there
would not be any reason to list them here.

Furthermore, the second interpretation agrees with    15.1/7:

"An exception is considered caught when initialization is complete for the
formal parameter of the corresponding catch clause, or when terminate() or
unexpected() is entered due to a throw."

> 2) with reading number 2, uncaught_exception() will never be true inside
> terminate(), whether the call has been explicit or not. Checking
> uncaught_exception() inside terminate() might be of some use, so why
> lose such capability? Moreover, the phrase "for any reason other than an
> explicit call" would be redundant. I don't think a phrase complex such
> as that might slip in by mistake.

Not so - if a destructor invoked during stack unwinding, calls terminate()
directly - then uncaught_exception() will return true even after terminate()
has been entered. On the other hand, if that destructor throws an exception
instead of calling terminate() directly, then uncaught_exception() will
return false once terminate() has been entered.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]