From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10056 invoked by alias); 24 Apr 2003 22:06: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 10031 invoked by uid 71); 24 Apr 2003 22:06:01 -0000 Date: Thu, 24 Apr 2003 22:06:00 -0000 Message-ID: <20030424220601.10030.qmail@sources.redhat.com> To: bkoz@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Benjamin Kosnik Subject: Re: libstdc++/10132: filebuf destructor throws exceptions Reply-To: Benjamin Kosnik X-SW-Source: 2003-04/txt/msg01057.txt.bz2 List-Id: The following reply was made to PR libstdc++/10132; it has been noted by GNATS. From: Benjamin Kosnik To: =?ISO-8859-1?Q?P=E9tur_Run=F3lfsson?= Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/10132: filebuf destructor throws exceptions Date: Thu, 24 Apr 2003 16:58:33 -0500 >> Here's something to think about. I think this is pretty good. >> Something like it will have to be done for the corresponding >> underflow bits. > >Maybe I'm missing something, but how does this fix the bug if >some exceptions are rethrown? In that exceptional case, there would still be a bug. It's still better than what's going on now. >Also, what's the rationale behind rethrowing some but not all >exceptions? Why would you propogate when the the exception can be cleaned 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 think that basic_filebuf should catch exceptions thrown >by use_facet or codecvt members. Why? >It is clear from 27.6.2.1 etc. that streambuf members may throw; Yes. That's not what the issue is, however. I see three ways to fix this. 1) make non-virtual codecvt MF's throw(), wrap all virtual calls with try, and in the catch block return codecvt_base::error. 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. 3) try to deal with the codecvt errors at the point of usage, ie in underflow/overflow. I think this makes the most sense. -benjamin