public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sebor at roguewave dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work Date: Wed, 02 Jul 2003 01:02:00 -0000 [thread overview] Message-ID: <20030702010246.27201.qmail@sources.redhat.com> (raw) In-Reply-To: <20030315103601.10093.peturr02@ru.is> 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
next prev parent reply other threads:[~2003-07-02 1:02 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20030315103601.10093.peturr02@ru.is> 2003-07-01 10:08 ` peturr02 at ru dot is 2003-07-02 1:02 ` sebor at roguewave dot com [this message] 2003-07-24 15:47 ` peturr02 at ru dot is 2003-07-24 17:08 ` sebor at roguewave dot com 2003-07-24 20:43 ` peturr02 at ru dot is 2003-07-24 22:34 ` sebor at roguewave dot com 2003-09-03 8:17 ` peturr02 at ru dot is 2003-09-03 16:25 ` [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] " pinskia at gcc dot gnu dot org 2003-10-16 2:53 ` mmitchel at gcc dot gnu dot org 2003-10-24 7:59 ` bkoz at gcc dot gnu dot org 2003-11-27 8:14 ` cvs-commit at gcc dot gnu dot org 2003-11-27 9:05 ` pinskia at gcc dot gnu dot org 2003-12-04 3:09 ` cvs-commit at gcc dot gnu dot org 2003-12-04 3:11 ` cvs-commit at gcc dot gnu dot org 2003-12-04 8:21 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030702010246.27201.qmail@sources.redhat.com \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).