RE: libstdc++/10132: filebuf destructor throws exceptions

["Pétur Runólfsson" <peturr02@ru.is>]

The following reply was made to PR libstdc++/10132; it has been noted by GNATS.

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: "Benjamin Kosnik" <bkoz@redhat.com>
Cc: <gcc-bugs@gcc.gnu.org>,
	<gcc-gnats@gcc.gnu.org>
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