This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
RE: libstdc++/10132: filebuf destructor throws exceptions
- From: Pétur Runólfsson <peturr02 at ru dot is>
- To: "Benjamin Kosnik" <bkoz at redhat dot com>
- Cc: <gcc-bugs at gcc dot gnu dot org>,<gcc-gnats at gcc dot gnu dot org>
- Date: Fri, 25 Apr 2003 21:36:55 -0000
- Subject: RE: libstdc++/10132: filebuf destructor throws exceptions
> >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 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.
>
> 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