Title
§[res.on.exception.handling]#3 cannot apply to types with implicitly declared destructors
Status
new
Section
[res.on.exception.handling]
Submitter
Nevin Liber

Created on 2019-06-28.00:00:00 last changed 15 months ago

Messages

Date: 2023-01-29.11:23:47

Proposed resolution:

This wording is relative to N4820.

  1. Modify [res.on.exception.handling] as indicated:

    -3- Destructor operations defined in the C++ standard library shall not throw exceptions. Every explicitly declared destructor in the C++ standard library shall behave as if it had a non-throwing exception specification.

Date: 2023-01-15.00:00:00

[ 2023-01-29; Daniel comments ]

This issue has very much overlap with LWG 3854.

Date: 2019-08-23.18:06:54

[ 2019-07 Issue Prioritization ]

Priority to 3 after discussion on the reflector.

Date: 2019-06-28.00:00:00

[res.on.exception.handling]#3 says:

Destructor operations defined in the C++ standard library shall not throw exceptions. Every destructor in the C++ standard library shall behave as if it had a non-throwing exception specification.

However, types like pair and array have implicitly declared destructors, where [except.spec]#8 applies:

The exception specification for an implicitly-declared destructor, or a destructor without a noexcept-specifier, is potentially-throwing if and only if any of the destructors for any of its potentially constructed subobjects is potentially-throwing or the destructor is virtual and the destructor of any virtual base class is potentially throwing.

We can relax [res.on.exception.handling] to only cover explicitly declared destructors because if they hold a user type where the destructor throws then we get UB from [res.on.functions]#2:

In particular, the effects are undefined in the following cases: […]

  1. […]

  2. (2.4) — if any replacement function or handler function or destructor operation exits via an exception, unless specifically allowed in the applicable Required behavior: paragraph.

  3. […]

and the referred to UB happens before [res.on.exception.handling] could apply.

History
Date User Action Args
2023-01-29 11:23:47adminsetmessages: + msg13227
2019-07-23 15:26:26adminsetmessages: + msg10510
2019-06-30 17:58:08adminsetmessages: + msg10471
2019-06-28 00:00:00admincreate