[Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work

["sebor at roguewave dot com" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10093



------- Additional Comments From sebor at roguewave dot com  2003-07-02 01:02 -------
Subject: Re:  Regression: Setting failbit in exceptions
 doesn't work

peturr02 at ru dot is wrote:

...
> I don't think there is any doubt that setstate(failbit) should throw if
> failbit is set in exceptions(), the question is whether the (un)formatted
> input/output functions should catch those exceptions. Some parts of the
> standard imply that the exceptions should be caught, some imply that they
> should not be caught.

My feeling is that if setstate() should end up throwing an exception
some exception should always propagate out of the calling function.

>  
...
> basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>& sb,
>                   char_type delim );
> 
> Notice bullet 4:
>   an exception occurs (in which case, the exception is caught but not rethrown).
> I read this to mean that exceptions thrown by either operations on sb or on
> rdbuf() should not propagate from this function, even if badbit is set in
> exceptions().

I don't think that's the intended interpretation but I agree that
it's a possible one. I would like to believe that the intent here
was only to swallow exceptions thrown from calls on sb (although
I don't like that either).

> This is inconsistent with the rest of the (un)formatted
> input/output functions. This function also differs from
> operator>>(basic_streambuf* sb) which rethrows exceptions from sb if failbit is
> on in exceptions().

Right. I don't think swallowing the exception is correct. IMO,
if exceptions are on, the function should rethrow the exception
no matter where it comes from. The reason for exceptions in
iostreams being optional is to provide backward compatibility
with classic iostreams. Once they're on there's no reason to
swallow them.

The more interesting question, IMO, is what bit to set if one
of the virtual calls on sb throws an exception. Should badbit
be set? I would be inclined to say no since the purpose of the
bit is to indicate some unrecoverable error in the stream
object's streambuf, but not necessarily such an error in the
argument. The stream itself might be perfectly fine after the
exception. My approach would be to set failbit in this case
(which is what our implementation does). If failbit is also
set in exceptions, the original exception is rethrown. This
is done without causing badbit to be set.

Martin