This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
current_exception may fail withbad_allocSection: 17.9.7[propagation]Status:CD1Submitter: Alisdair MeredithOpened: 2007-10-10Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [propagation].
View all issues withCD1 status.
Discussion:
I understand that the attempt to copy an exception may run out of memory,but I believe this is the only part of the standard that mandates failurewith specificallybad_alloc, as opposed to allowing animplementation-defined type derived frombad_alloc. For instance, the Corelanguage for a failed new expression is:
Any other allocation function that fails to allocate storage shall indicatefailure only by throwing an exception of a type that would match a handler(15.3) of type
std::bad_alloc(18.5.2.1).
I think we should allow similar freedom here (or add a blanketcompatible-exception freedom paragraph in 17)
I prefer the clause 17 approach myself, and maybe clean up any outstandingwording that could also rely on it.
Although filed against a specific case, this issue is a problem throughoutthe library.
[Bellevue:]
Is issue bigger than library?
No - Core are already very clear about their wording, which is inspiration for the issue.
While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
Accept the broad view and move to ready
Proposed resolution:
Add the following exemption clause to 16.4.6.14[res.on.exception.handling]:
A function may throw a type not listed in itsThrows clause so long as it isderived from a class named in theThrows clause, and would be caught by anexception handler for the base type.