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

### 2136. Postconditions vs. exceptions

Section: 16.3.2 [structure] Status: Open Submitter: Jens Maurer Opened: 2012-03-08 Last modified: 2021-06-25

Priority: 3

View all issues with Open status.

Discussion:

The front matter in clause 17 should clarify that postconditions will not hold if a standard library function exits via an exception. Postconditions or guarantees that apply when an exception is thrown (beyond the basic guarantee) are described in an "Exception safety" section.

[ 2012-10 Portland: Move to Open ]

Consensus that we do not clearly say this, and that we probably should. A likely location to describe the guarantees of postconditions could well be a new sub-clause following 99 [res.on.required] which serves the same purpose for requires clauses. However, we need such wording before we can make progress.

Also, see 2137 for a suggestion that we want to see a paper resolving both issues together.

[2015-05-06 Lenexa: EirkWF to write paper addressing 2136 and 2137]

MC: Idea is to replace all such "If no exception" postconditions with "Exception safety" sections.

[2021-06-20; Daniel comments]

An informal editorial change suggestion has recently been made whose editorial implementation would promote the idea that the default assumption is that Postconditions: are only met if the function doesn't exit with an exception.

After analyzing all current existing Postconditions: elements the following seems to hold: Affected by this issue are only non-`noexcept` functions and mostly non-constructor functions (unless the Postconditions: element says something about the value of its arguments). Most existing Postconditions seem to be intended to apply only in non-exceptional cases. I found some where this is presumably not intended, namely those of the expressions `os << x` and `is >> v` in Tables [tab:rand.req.eng] and [tab:rand.req.dist], maybe also 29.11.2.4 [time.zone.db.remote] p4.

Nonetheless, the editorial change seems to be applicable even without having this issue resolved, because it doesn't actually change the normative state by itself.

Proposed resolution: