Movatterモバイル変換

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

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

Section: 17.9.7[propagation]Status:CD1Submitter: Stephan T. LavavejOpened: 2008-03-26Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [propagation].

View all issues withCD1 status.

Discussion:

As of N2521, the Working Paper appears to be silent about whatcurrent_exception() should do if it tries to copy the currently handledexception and its copy constructor throws. 17.9.7[propagation]/7 says "If thefunction needs to allocate memory and the attempt fails, it returns anexception_ptr object that refers to an instance ofbad_alloc.", butdoesn't say anything about what should happen if memory allocationsucceeds but the actual copying fails.

I see three alternatives: (1) return anexception_ptr object that refersto an instance of some fixed exception type, (2) return anexception_ptrobject 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) callterminate().

I believe thatterminate() is the most reasonable course of action, butbefore we go implement that, I wanted to raise this issue.

[Peter's summary:]

The current practice is to not have throwing copy constructors inexception classes, because this can lead toterminate() as described in14.6.2[except.terminate]. Thus callingterminate() in this situation seemsconsistent and does not introduce any new problems.

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

The CWG agreed with the position thatstd::uncaught_exception() shouldreturnfalse during the copy to the exception object and thatstd::terminate()should not be called if that constructor exits with an exception.

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

Option (2) cannot be adopted by itself, because a potential infiniterecursion 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 exceptionobject throws an exception, the function returns anexception_ptr thatrefers to the thrown exception or, if this is not possible, to aninstance ofbad_exception.

[Note: The copy constructor of the thrown exception may also fail, sothe implementation is allowed to substitute abad_exception to avoidinfinite recursion.-- end note.]

Rationale:

[San Francisco:]

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

Pete will make the required editorial tweaks to rectify this.