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.

### 746. `current_exception` may fail with `bad_alloc`

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.