https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71950
Austin Kramer <skaianhero at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |skaianhero at gmail dot com
--- Comment #2 from Austin Kramer <skaianhero at gmail dot com> ---
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. 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.
- Just use errno: AFAIK there's no spec saying that errno should be set in a
fstream::open call (from the perspective of the caller), but in practice it
seems to be set to the correct value for the underlying I/O error (though this
may be platform-dependent). If g++ could internally require errno to be set
deeper within the file operations and remain set until control returns to
fstream's functions, then those functions could re-throw a fresh exception
after basic_ios::clear with a more helpful message. But like you said, it's
hard (and perhaps wrong) to fully ensure that all sources of errors set errno
appropriately.
That said, I'm not sure how, in a world without PR 66145 causing issues, the
C++11 version would cleanly propagate the system_error details. Maybe it just
doesn't, and this fix would be used to address that as well.
