Topic: DR: std::uncaught_exception
Author: restor <akrzemi1@gmail.com>
Date: Thu, 9 Jul 2009 11:53:33 CST Raw View
Hi,
I believe, the definition of std::uncaught_exception needs some more
specification. I am not sure if this should be an another DR or a
supplement to 475.
All the information about std::uncaught_exception (apart from one
destructor in the IOStreams library) is gathered in three sections:
15.1 (7)
A throw-expression with no operand rethrows the currently handled
exception (15.3). The exception is
reactivated with the existing temporary; no new temporary exception
object is created. The exception is
no longer considered to be caught; therefore, the value of
std::uncaught_exception() will again be true.
15.5.3 The std::uncaught_exception() function [except.uncaught]
The function std::uncaught_exception() returns true after completing
evaluation of the object to be
thrown until completing the initialization of the exception-
declaration in the matching handler (18.8.4).
This includes stack unwinding. If the exception is rethrown (15.1),
std::uncaught_exception() returns
true from the point of rethrow until the rethrown exception is caught
again.
18.8.4 uncaught_exception [uncaught]
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(). [ Note: This
includes stack unwinding (15.2). end note ]
2 Remarks: When uncaught_exception() returns true, throwing an
exception can result in a call of
terminate() (15.5.1).
First, definitions 15.5.3 and 18.8.4 seem inconsistent with one
another with respect to what happens when terminate or unexpected is
called, and when an exception is rethrown (this is covered by DR 475).
Second, the two definitions only say when the function should return
true. They never say when/if the function shall return false. If I
read the definition too precisely, the implementation where
std::uncaught_exception always returns true is valid. Given that the
goal of std::uncaught_exception is to say when a throw might trigger a
call to terminate, it makes some sense, but it would be counter to
what all the books say, and counter to intuition.
Third, if I am wrong and std::uncaught_exception must return false if
no exception has been thrown, then there is a bug in 15.1 (7), where
the standard reads "[...] rethrows the currently handled exception.
[...] the value of std::uncaught_exception() will ***again*** be
true". The "again" is incorrect. The following example illustrates
that.
void fun() try {
throw 0;
}
catch( int i ) {
assert( uncaught_exception() == true );
throw;
}
struct Type {
~Type() {
try {
fun();
} catch( int i ) { }
}
};
int main() try {
Type t;
throw 1;
}
catch( int i ) {
}
This example does not call terminate. It does not throw exceptions
from the destructor. It only throws an exception within the
destructor. There is one re-throw instruction (in function fun). Both
before and after the re-throw, the value of std::uncaught_exception is
true. The phrase "therefore, the value of std::uncaught_exception()
will again be true" should be deleted.
Perhaps both definitions could be changed to something like:
Returns:
true ***iff*** there exists at least one temporary exception object
for
which evaluation of a throw-expression has completed and until
initialization of the exception-declaration in the matching handler
has completed ... etc.
Regards,
&rzej
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]