All exception handling in iostreams could stand to be cleaned up and
made more consistent. See also http://www2.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#394

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hello,

there already exist two active DR's for the wording of 27.6.1.2.3/13
from 14882:2003(E), namely

http://www2.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64
http://www2.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#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 27.6.2.5.3/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 7.6.1.2.3/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 solution:

(a) In 27.6.1.2.3/15 (N2134) change the sentence

"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."

to

"If an exception was thrown while extracting a character from *this,
the function sets failbit in error state, and if failbit is on in
exceptions()
(27.4.4.3), then the caught exception is rethrown."

(b) In 27.6.2.5.3/8 (N2134) change the sentence

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

to

"- an exception occurs while getting a character from sb (in which
case the exception is caught)."

Greetings from Bremen,

Daniel Kr   gler


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]