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.
Section: 17.9.7 [propagation] Status: CD1 Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [propagation].
View all issues with CD1 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 failure with specifically bad_alloc, as opposed to allowing an implementation-defined type derived from bad_alloc. For instance, the Core language for a failed new expression is:
Any other allocation function that fails to allocate storage shall indicate failure 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 blanket compatible-exception freedom paragraph in 17)
I prefer the clause 17 approach myself, and maybe clean up any outstanding wording that could also rely on it.
Although filed against a specific case, this issue is a problem throughout the 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.13 [res.on.exception.handling]:
A function may throw a type not listed in its Throws clause so long as it is derived from a class named in the Throws clause, and would be caught by an exception handler for the base type.