From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22250 invoked by alias); 23 Mar 2003 20:26:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 22236 invoked by uid 71); 23 Mar 2003 20:26:00 -0000 Date: Sun, 23 Mar 2003 20:30:00 -0000 Message-ID: <20030323202600.22235.qmail@sources.redhat.com> To: jlquinn@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Martin Sebor Subject: Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work Reply-To: Martin Sebor X-SW-Source: 2003-03/txt/msg01541.txt.bz2 List-Id: The following reply was made to PR libstdc++/10093; it has been noted by GNATS. From: Martin Sebor 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