https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71950
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Austin Kramer from comment #2)
> Well, if the actual throw happens obliviously in basic_ios::clear after
> fstream::open detects the error, it wouldn't be hard to have fstream::open
> catch the exception and re-throw a more helpful one.
That would add overhead for exception handling and the vast majority of users
do not use exceptions with fstream.
The real hard part
> though is propagating the error details up to fstream::open in the first
> place. The call stack goes through several basic succeed/fail returns, some
> of which are public-facing functions.
>
> There are 2 reasonable solutions I can think of that don't break the API,
> but neither are particularly clean.
>
> - Gratuitous overloading: Replace some intermediate basic_filebuf and
> __basic_file calls with ones that propagate an error code, and have their
> public-facing variants wrap the new versions and reduce the return value to
> the compliant types.
Users can specialize basic_filebuf so we can't rely on non-standard functions.
I don't think it's worth changing anything here.
