This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

### 820. `current_exception()`'s interaction with throwing copy ctors

Section: 17.9.7 [propagation] Status: CD1 Submitter: Stephan T. Lavavej Opened: 2008-03-26 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [propagation].

View all issues with CD1 status.

Discussion:

As of N2521, the Working Paper appears to be silent about what `current_exception()` should do if it tries to copy the currently handled exception and its copy constructor throws. 17.9.7 [propagation]/7 says "If the function needs to allocate memory and the attempt fails, it returns an `exception_ptr` object that refers to an instance of `bad_alloc`.", but doesn't say anything about what should happen if memory allocation succeeds but the actual copying fails.

I see three alternatives: (1) return an `exception_ptr` object that refers to an instance of some fixed exception type, (2) return an `exception_ptr` object that refers to an instance of the copy ctor's thrown exception (but if that has a throwing copy ctor, an infinite loop can occur), or (3) call `terminate()`.

I believe that `terminate()` is the most reasonable course of action, but before we go implement that, I wanted to raise this issue.

[ Peter's summary: ]

> The current practice is to not have throwing copy constructors in exception classes, because this can lead to `terminate()` as described in 14.6.2 [except.terminate]. Thus calling `terminate()` in this situation seems consistent and does not introduce any new problems.

> However, the resolution of core issue 475 may relax this requirement:

> > The CWG agreed with the position that `std::uncaught_exception()` should return `false` during the copy to the exception object and that `std::terminate()` should not be called if that constructor exits with an exception.

> Since throwing copy constructors will no longer call `terminate()`, option (3) doesn't seem reasonable as it is deemed too drastic a response in a recoverable situation.

> Option (2) cannot be adopted by itself, because a potential infinite recursion will need to be terminated by one of the other options.

Proposed resolution:

Add the following paragraph after 17.9.7 [propagation]/7:

> Returns (continued): If the attempt to copy the current exception object throws an exception, the function returns an `exception_ptr` that refers to the thrown exception or, if this is not possible, to an instance of `bad_exception`.

> [Note: The copy constructor of the thrown exception may also fail, so the implementation is allowed to substitute a `bad_exception` to avoid infinite recursion. -- end note.]

Rationale:

[ San Francisco: ]

> Pete: there may be an implied assumption in the proposed wording that current_exception() copies the existing exception object; the implementation may not actually do that.

> Pete will make the required editorial tweaks to rectify this.