Re: Clarification needed for 18.6.4: terminate() and
uncaught_excaption()
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 ]