Re: Unusual program termination and exception handling
On 13 Jun., 22:46, Nikolay Ivchenkov <ts...@mail.ru> wrote:
I would like to ask about the required behavior of the programs listed
below (according to C++03 and C++0x).
Example 1:
#include <cstdlib>
#include <iostream>
struct X
{
~X()
{
try
{
throw;
}
catch (int)
{
std::cout << "~X() - catch" << std::endl;
}
}
} x;
void on_exit()
{
try
{
throw;
}
catch (int)
{
std::cout << "on_exit() - catch" << std::endl;
}
}
int main()
{
std::atexit(on_exit);
try
{
throw 0;
}
catch (int)
{
std::exit(0);
}
}
Must the exception handler in main() be considered active when the
control is transferred to dtor ~X() or to on_exit()?
For C++03 the situation is probably unclear in regard to the question
whether the throw-expression of within ~X() satisfies the criteria
mentioned in 15.1/7, but this became resolved with the P/R given by
core defect 208. Thus in C++0x it is clarified that we can invoke a
series of try/catch blocks with throw expressions without operand.
The nomenclature of an active handler did not exist in C++03
(even though we have the undefined notion of a "reactivated"
exception), but it seems rather clear to me that without the
additional level of complexity introduced by the second throw-
expression without operand the invocation of either the
destructor of x or the invocation of on_exit() happens before
"the corresponding catch clause exits" (15.1/7), following the
description what happens during the call of exit
([lib.support.start.term]/8). My interpretation is, that the
exit of the handler does actually happen, when bullet three
of the list is evaluated:
"Finally, control is returned to the host environment [..]"
but not before. This again means that the two first bullets
describing the effects of exit(0) should happen in the context
of an unfinished exception handler (15.1 [except.throw]/7), which
means that the evaluation of the throw expressions without
operands will just reactivate the exception as described in
15.1 [except.throw]/6.
Does this answer your question?
Example 2:
#include <cstdlib>
#include <exception>
#include <iostream>
struct X
{
~X()
{
std::cout << (int)std::uncaught_exception() << std::endl;
}
} x;
struct Y
{
~Y()
{
std::exit(0);
}
};
void on_terminate()
{
std::cout << "on_terminate()" << std::endl;
std::abort();
}
int main()
{
std::set_terminate(on_terminate);
try
{
Y y;
throw 0;
}
catch (int) {}
}
Isn't the behavior of this program undefined? Must
std::uncaught_exception() return true? Note: GNU C++ calls
std::terminate.
Which version of GNU C++ are you referring to?
I don't think that undefined behaviour is involved here.
In summary, a conforming implementation should not call
std::terminate and I believe that std::uncaught_exception()
should evaluate to true within the destructor of X. C++03
already describes that in sub-clause [except.ctor].
Especially p. 1:
"As control passes from a throw-expression to a handler,
destructors are invoked for all automatic objects
constructed since the try block was entered."
This makes it clear that the dtor of the automatic object
y is called before entering the actual handler. I agree
that some part of the description of the "state changes"
during exception handling is less than clear (again see core
issue 475), but even the survey given for core issue 475
shows that no compiler got the value of
std::uncaught_exception() wrong during stack unwinding (it
shall evaluate to true), probably because
[except.uncaught]/1 says so very explicitly.
Now the destructor of y invokes exit(0). This is no
special case mentioned on the bulleted list of
[except.terminate]/1 (and not even in C++0x), so no
reason to terminate. Normal handling of this function
follows the description of 18.3 [lib.support.start.term]/8:
This requires that destructors of objects with static
storage duration will be destroyed, therefore the
destructor of X will be called. Since we are still on
stack-unwinding, the value reported by
std::uncaught_exception() is still true. The insertion
into std::cout should still be OK, following the
description of [lib.iostream.objects] (which has been
clarified a bit by LWG issues 369, 574, and 1123). The
final bullet describes
"Finally, control is returned to the host environment."
IMO this clearly excludes the possibility that the
exception handler in main can be entered and thus the
program should end with a status /successful termination/.
I don't see any part of the wording from which I could
deduce the possibility of undefined behaviour or a call
to std::terminate(). Recent gcc 4.5.0 or Visual Studio
2010 perform the steps as described.
Do you have some specific wording in your mind, that should
lead to this conclusion of causing UB or calling terminate?
Example 3:
#include <cstdlib>
#include <exception>
#include <iostream>
struct X
{
~X()
{
std::cout << "~X()" << std::endl;
}
} x;
void on_terminate()
{
std::exit(0);
}
int main()
{
std::set_terminate(on_terminate);
throw;
}
Isn't the behavior of this program undefined? According to 18.8.3.1,
"A terminate_handler shall terminate execution of the program without
returning to the caller." A terminate handler that calls std::exit can
eventually terminate execution of the program without returning to the
caller. It seems that the requirement is satisfied in this case.
I don't see why this program should possibly invoke undefined
behaviour. 15.1 [except.throw]/8 says:
"If no exception is presently being handled, executing a throw-
expression with no operand calls terminate() (15.5.1)."
which is the case here. 15.5.1 [except.terminate] goes further
into this in bullet 6
"when a throw-expression with no operand attempts to rethrow an
exception and no exception is being handled (15.1),"
which is nothing new. The invocation of the registered terminate
handler calls exit(0) as described in the example before and
with the same consequences, i.e. the destructor of x is invoked,
and later on the iostream objects will be flushed (see the LWG
issue mentioned above). After this the program ends with
status /successful termination/ as in the example before.
If you think that this is not clear from the wording, could you
please provide a hint, in which sense?
Finally, is a terminate handler allowed to throw an exception?
No, I don't see this freedom given (in contrast to a user-provided
unexpected handler), see [lib.terminate.handler]/2:
"Required behavior: A terminate_handler shall terminate execution
of the program without returning to the caller."
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]