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

639. Still problems with exceptions during streambuf IO

Section: 31.7.5.3.3 [istream.extractors], 31.7.6.3.3 [ostream.inserters] Status: NAD Submitter: Daniel Krügler Opened: 2007-02-17 Last modified: 2017-04-22

Priority: Not Prioritized

View all other issues in [istream.extractors].

View all issues with NAD status.

Discussion:

There already exist two active DR's for the wording of [istream::extractors]/13 from 14882:2003(E), namely 64⁽ⁱ⁾ and 413⁽ⁱ⁾.

Even with these proposed corrections, already maintained in N2134, I have the feeling, that the current wording does still not properly handle the "exceptional" situation. The combination of para 14

"[..] Characters are extracted and inserted until any of the following occurs:

[..]

- an exception occurs (in which case the exception is caught)."

and 15

"If the function inserts no characters, it calls setstate(failbit), which may throw ios_base::failure (27.4.4.3). If it inserted no characters because it caught an exception thrown while extracting characters from *this and failbit is on in exceptions() (27.4.4.3), then the caught exception is rethrown."

both in N2134 seems to imply that any exception, which occurs *after* at least one character has been inserted is caught and lost for ever. It seems that even if failbit is on in exceptions() rethrow is not allowed due to the wording "If it inserted no characters because it caught an exception thrown while extracting".

Is this behaviour by design?

I would like to add that its output counterpart in 31.7.6.3.3 [ostream.inserters]/7-9 (also N2134) does not demonstrate such an exception-loss-behaviour. On the other side, I wonder concerning several subtle differences compared to input::

1) Paragraph 8 says at its end:

"- an exception occurs while getting a character from sb."

Note that there is nothing mentioned which would imply that such an exception will be caught compared to [istream::extractors]/14.

2) Paragraph 9 says:

"If the function inserts no characters, it calls setstate(failbit) (which may throw ios_base::failure (27.4.4.3)). If an exception was thrown while extracting a character, the function sets failbit in error state, and if failbit is on in exceptions() the caught exception is rethrown."

The sentence starting with "If an exception was thrown" seems to imply that such an exception *should* be caught before.

Proposed resolution:

(a) In [istream::extractors]/15 (N2134) change the sentence

If the function inserts no characters, it calls setstate(failbit), which may throw ios_base::failure (27.4.4.3). If it inserted no characters because it caught an exception thrown while extracting characters from *this an exception was thrown while extracting a character from *this, the function sets failbit in error state, and failbit is on in exceptions() (27.4.4.3), then the caught exception is rethrown.

(b) In 31.7.6.3.3 [ostream.inserters]/8 (N2134) change the sentence:

Gets characters from sb and inserts them in *this. Characters are read from sb and inserted until any of the following occurs:

• end-of-file occurs on the input sequence;
• inserting in the output sequence fails (in which case the character to be inserted is not extracted);
• an exception occurs while getting a character from sb (in which case the exception is caught).

Rationale:

This extractor is described as a formatted input function so the exception behavior is already specified. There is additional behavior described in this section that applies to the case in which failbit is set. This doesn't contradict the usual exception behavior for formatted input functions because that applies to the case in which badbit is set.