Is the lifetime of an exception affected by other exceptions? - c++

Question

As a follow-up to my previous question:
If I change the code as follows:
struct ExceptionBase : virtual std::exception{};
struct SomeSpecificError : virtual ExceptionBase{};
struct SomeOtherError : virtual ExceptionBase{};
void MightThrow();
void HandleException();
void ReportError();
int main()
{
try
{
MightThrow();
}
catch( ... )
{
HandleException();
}
}
void MightThrow()
{
throw SomeSpecificError();
}
void HandleException()
{
try
{
throw;
}
catch( ExceptionBase const & )
{
// common error processing
}
try
{
throw;
}
catch( SomeSpecificError const & )
{
// specific error processing
}
catch( SomeOtherError const & )
{
// other error processing
}
try
{
ReportError();
}
catch( ... )
{
}
}
void ReportError()
{
throw SomeOtherError();
}
The "last handler" for the original exception (i.e. the one in main) has not exited when the second exception is thrown, so are both exceptions active? Is the original exception still available once we leave the handler for the second exception?

Answer 1

C++11 (N3242):
15.1p4: The memory for the exception object is allocated in an unspecified way, except as noted in 3.7.4.1. If a
handler exits by rethrowing, control is passed to another handler for the same exception. The exception
object is destroyed after either the last remaining active handler for the exception exits by any means other
than rethrowing, or the last object of type std::exception_ptr (18.8.5) that refers to the exception object is
destroyed, whichever is later.
(std::exception_ptr is a C++11 feature, and isn't used in your example code.)
15.3p7: A handler is considered active when initialization is complete for the formal parameter (if any) of the catch clause. ... A handler
is no longer considered active when the catch clause exits or when std::unexpected() exits after being
entered due to a throw.
15.3p8: The exception with the most recently activated handler that is still active is called the currently handled exception.
15.1p8: A throw-expression with no operand rethrows the currently handled exception (15.3).
Or equivalently, I think, throw; always refers to the exception caught by the innermost catch block which is currently executing. Except that I haven't defined 'innermost' and 'executing' as carefully as the Standard defined all its terms above.
And yes, more than one exception object can be allocated at a time, and C++ is required to make sure they live long enough to do "the right thing" when you try to rethrow.

Answer 2

Not sure how standard it is, but if i add a throw; right before the end of HandleException and compile with g++, the resulting program tells me this:
root#xxxx [~/code]# ./a.out
terminate called after throwing an instance of 'SomeSpecificError'
what(): 17SomeSpecificError
Aborted
Note the exception type. That's the exception that was thrown in MightThrow, not the one from ReportError.
VS2010 reports a SomeSpecificError as well.

Answer 3

There is only one "active exception" at a time. When you throw another exception in an exception handler, in effect you are changing the type of the exception that is being propagated up the stack.
(As an aside, is all this necessary? Do you really find this code easy to read?)
[update]
As for the standard reference... ISO/IEC 14882:2003, section 15.3 [except.handle], paragraph 8 reads:
An exception is considered handled upon entry to a handler. [Note: the
stack will have been unwound at that point. ]
So another way to say this is, as soon as you enter the catch block, the original exception is no longer active.
Also, the uncaught_exception() function will return false as soon as the catch block is entered. Section 15.5.3 [except.uncaught] reads:
The function
bool uncaught_exception() throw()
returns true after completing evaluation of the object to be thrown until completing the
initialization of the exception-declaration in the matching handler
(18.6.4). This includes stack unwinding. If the exception is rethrown
(15.1), uncaught_exception() returns true from the point of rethrow
until the rethrown exception is caught again.
[update 2]
Also relevant is section 15.3 paragraph 4:
The memory for the temporary copy of the exception being thrown is
allocated in an unspecified way, except as noted in 3.7.3.1. The
temporary persists as long as there is a handler being executed for
that exception. In particular, if a handler exits by executing a
throw; statement, that passes control to another handler for the same
exception, so the temporary remains. When the last handler being
executed for the exception exits by any means other than throw; the
temporary object is destroyed and the implementation may deallocate
the memory for the temporary object; any such deallocation is done in
an unspecified way. The destruction occurs immediately after the
destruction of the object declared in the exception-declaration in the
handler.
So the original exception is destroyed as soon as the handler is exited via any means other than a naked throw;. So if you throw some other exception, that exits the handler and destroys the original exception.