public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Martin Sebor <sebor@roguewave.com> To: jlquinn@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work Date: Sun, 23 Mar 2003 20:30:00 -0000 [thread overview] Message-ID: <20030323202600.22235.qmail@sources.redhat.com> (raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1959 bytes --] The following reply was made to PR libstdc++/10093; it has been noted by GNATS. From: Martin Sebor <sebor@roguewave.com> To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work Date: Sun, 23 Mar 2003 13:18:57 -0700 Pétur Runólfsson wrote: ... > > Note the "during input". I read that as meaning that this refers only > to exceptions thrown by the call to num_get::get(), not to exceptions > thrown from other functions the extractors may call. The general requirements on what causes exceptions to be caught and rethrown are buried in 27.6.1.1, p1-4. According to the text only calls to members of streambuf are supposed to be checked for exceptions. But because it's not possible to distinguish between an exception thrown by, say, a (virtual) member function of ctype called from num_get::get() and one thrown by a (virtual) streambuf member called (indirectly, via an istreambuf_iterator member) from num_get::get(), the requirement cannot realistically be taken to mean just exceptions thrown during a call to num_get ::get() and not, for instance, ctype::is() called by the istream ::sentry ctor. IMO, stream members should consistently catch all exceptions from any functions they may call. > ... > The whole text about the meaning of exceptions() and the handling of > exceptions thrown during calls to I/O functions seems rather messy. > Perhaps someone more familiar with the standard cares to comment? I agree that error handling in iostreams (and locale) in general and exception handling in particular is less than perfect. I have filed a number of issues(*) in an attempt to clean up this area but I have a feeling there is more work to be done. (*) A number of them aren't listed yet (they should be in Revision 25 of the issues list), but this one is http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#309 Regards Martin
next reply other threads:[~2003-03-23 20:26 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-03-23 20:30 Martin Sebor [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-03-26 2:56 Martin Sebor 2003-03-24 18:26 Pétur Runólfsson 2003-03-24 11:09 Pétur Runólfsson 2003-03-23 19:26 Pétur Runólfsson 2003-03-23 6:56 Jerry Quinn 2003-03-22 15:22 paolo 2003-03-15 10:36 peturr02
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=20030323202600.22235.qmail@sources.redhat.com \ --to=sebor@roguewave.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=jlquinn@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).