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.