libstdc++/10132: filebuf destructor throws exceptions

[Pétur Runólfsson]

>     This is in violation of 17.4.4.8.

Yes.

>     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.)

This is disallowed by the resolution to DR 119. It won't
fix the problem either since the destructor calls other
functions that may throw (use_facet).

> 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.

It is clear, facets may throw any exceptions (except from those
members with throw() specs).

>     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? 

Probably just clean up and return.

>     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.

See 17.4.4.8 p3. All streambuf/filebuf members except the
destructor may throw exceptions of any type. Since the
standard doesn't require streambuf/filebuf members to catch
exceptions, I would expect them to propagate.

>     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.

Some facets do. Others (like codecvt or the *_put facets)
don't.

> Although, nothing (except exception-saftey paradoxes) keeps 
> derived/user-defined classes from doing this.

I believe user-defined facets are allowed to throw anything
they choose, whenever they choose from those members
without throw specs, and that the iostream library should
be prepared to deal with this.

Petur