[cxx-abi-dev] Details missing for EH 2.4.1 Overview of Throw Processing

[John McCall]

On Dec 19, 2011, at 7:58 PM, Dennis Handly wrote:
>> From: John McCall <rjmccall at apple.com>
>>> Does the last sentence mean that if there is a catch for what the copy
>>> constructor is throwing, it is ignored?
> 
>> I think this is just the ABI document being out-of-date vs. the standard.
>> DR 475 jumped around a lot, but the final resolution (March 2010) makes
>> it clear that we are *not* supposed to call std::terminate if an exception
>> is thrown during the copy-initialization of an exception object.
> 
> So we just go to whatever catch is active or std::terminate?

Right.  It's no longer special in any way, except that if you've allocated
an exception object (in Itanium-like exception schemes) you need to free it.

> But in any case, the copy constructor seems to be elided for both aC++ and
> g++.

Right.  One of the nice things about the change is that it no longer calls
out the final copy-construction as having special exception semantics,
which means you can now reasonably do copy-elision here.  I know many
compilers were doing it before anyway, with the special semantics also
being elided away.

>> We only terminate if an exception is thrown after the initialization is
>> complete, e.g.  by a destructor of that full-expression,
> 
> So does this need to be mentioned for __cxa_end_catch or is it the generated
> cleanup code for the throw?

I don't know what you mean.  __cxa_end_catch is not required
as part of the generated code for a throw expression.  I don't think it
ever was.

> Since copy constructor seems to be elided, there is no cleanup code for the
> throw.  (Unless some complex conditions or lots of temps?  But these wouldn't
> be the full-expression.)

Once you've called __cxa_allocate_exception, you must either throw
it or free it.

> g++ seems to not disallow that throw in __cxa_end_catch.
> aC++ does too but does get lost if a catch is present.

In general, the generated call to __cxa_end_catch at the end of a
catch clause can throw.  You can prove that it can't in some cases,
based on the caught exception object type or the CFG of the catch
clause.

John.