https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Davin McCall <davmac at davmac dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |davmac at davmac dot org
--- Comment #27 from Davin McCall <davmac at davmac dot org> ---
> Another option is to decide which to throw based on an environment variable,
> so > applications can choose whether they want the types thrown by the
> library to be > catchable by new code or old code.
Please don't do this. It will mean programs that require wrapper scripts just
to work properly, or problems with old-abi programs launching new-abi programs
and vice-versa, and will undoubtedly cause confusion when programs seem to work
correctly some of the time and not otherwise.
> But we might end up just throwing the new type, and saying old code needs to
> be > recompiled, or just to catch it as std::exception not
> std::ios_base::failure.
If you are going to mandate that old code needs to be recompiled (including if
you say that it should catch std::exception, since that requires altering the
code and therefore implies recompilation), I would suggest that you also bump
the soname; this is definitely an ABI break. At that point you can remove the
dual ABI anyway, since you only need to support the new one.
If you do not plan on bumping the soname, but will change the thrown exception
type to the new type, I would suggest that this change be made as soon as is
practically possible to avoid the production of further software being compiled
against the old ABI - which will then need to be recompiled when this change is
made. The less that needs to be recompiled the better, especially since that
was IIUC the reason for the creation of the dual ABI in the first place.
