From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24936 invoked by alias); 23 Apr 2003 03:47:06 -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 24899 invoked by uid 48); 23 Apr 2003 03:47:05 -0000 Date: Wed, 23 Apr 2003 03:47:00 -0000 Message-ID: <20030423034705.24898.qmail@sources.redhat.com> To: bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, peturr02@ru.is From: bkoz@gcc.gnu.org Reply-To: bkoz@gcc.gnu.org, bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, peturr02@ru.is, gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/10132: filebuf destructor throws exceptions X-SW-Source: 2003-04/txt/msg00951.txt.bz2 List-Id: Synopsis: filebuf destructor throws exceptions State-Changed-From-To: analyzed->feedback State-Changed-By: bkoz State-Changed-When: Wed Apr 23 03:47:05 2003 State-Changed-Why: This is in violation of 17.4.4.8. I'm thinking about adding throw() exception specifications to codecvt member funtions. This could be considered a tightening of exception specs, which is allowed in 17.4.4.8 p1 (although I remember some noise when the proposal to add throw() to dtors was suggested.) That should at least make the locale::facet policy on error reporting (22.2 - Standard locale categories p 2) clear, even though it won't necessarily remove the issue. To remove it completely, I'd have to do a try around the close() call in basic_filebuf::~basic_filebuf(). And what should happen in the catch? I believe the theory of error handling in the design of the io classes is that basic_ios/basic_istream/basic_ostream throw, catch, and propogate exceptions. The streambuf classes just return eof/-1 (showmanyc, pbackfail, seekoff, seekpos) or NULL (open, close) to report errors. The problem is the intersection of std::locale, which can throw on construction (locale(const char*), combine) and whenever a use_facet is used. Facets, as above, in practice use iostate or some other mechanism to report errors. Although, nothing (except exception-saftey paradoxes) keeps derived/user-defined classes from doing this. -benjamin http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10132