From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11806 invoked by alias); 25 Apr 2003 21:46:01 -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 11794 invoked by uid 71); 25 Apr 2003 21:46:01 -0000 Date: Fri, 25 Apr 2003 21:46:00 -0000 Message-ID: <20030425214601.11793.qmail@sources.redhat.com> To: bkoz@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= Subject: RE: libstdc++/10132: filebuf destructor throws exceptions Reply-To: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= X-SW-Source: 2003-04/txt/msg01185.txt.bz2 List-Id: The following reply was made to PR libstdc++/10132; it has been noted by GNATS. From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= To: "Benjamin Kosnik" Cc: , Subject: RE: libstdc++/10132: filebuf destructor throws exceptions Date: Fri, 25 Apr 2003 21:36:55 -0000 > >Also, what's the rationale behind rethrowing some but not all > >exceptions? >=20 > Why would you propogate when the the exception can be cleaned=20 > up at the > point of failure? If something that this function is not prepared to > deal with happens, then it can rethrow. I don't see that filebuf members can in general handle exceptions thrown by codecvt members. The best they can reasonably do is to catch the exception and return an error value. > >I don't think that basic_filebuf should catch exceptions thrown > >by use_facet or codecvt members.=20 >=20 > Why? 1. Consistency with the rest of the library, which allows exceptions to propagate. 2. basic_istream and basic_ostream allow the caller to decide on the exception handling policy. 3. When codecvt operations throw exceptions the filebuf is in general unreadable and left in an indeterminate state. This indicates that badbit should be set in rdstate(). For underflow(), this will only happen if an exception is thrown. > 1) make non-virtual codecvt MF's throw(), wrap all virtual calls with > try, and in the catch block return codecvt_base::error. I don't like this. It decides the exception handling policy for all users of codecvt, not just filebuf. > 2) try/catch in filebuf::~filebuf. The problem with this is that the > "cleanups" are quite difficult to do in ~filebuf if filebuf::close > fails, and we will end up either duplicating a bunch of filbuf::close, > or leaking memory. If filebuf::close() frees all resources, even when exceptions are thrown, ~filebuf won't have to do any cleanup. > 3) try to deal with the codecvt errors at the point of usage, ie in > underflow/overflow. I think this makes the most sense. If codecvt::in throws an exception, underflow can't produce any characters and hence must fail, so I don't see that this is possible. Petur