Re: Compiler assistance with making a C++ codebase exception safe

To my knowledge those options relate to exception specifications
rather than exceptions as a whole, the former just turns throw() into
noexcept, which doesn't seem like it'll help much with C++17 and above
code. The latter can be pretty helpful, but I think it only controls
the case where exception specifications are violated, such as a
noexcept method calling a method with no exception specification. Some
cases, like new expressions and compiler inserted cleanup into
constructors in the case of an exception happening aren't affected by
this from what I know. But more importantly, while they can help with
making the code compile without -fno-exceptions they don't really tell
you where and why implicit exception handling is being inserted, which
is what you'd need when trying to port the codebase to be exception
safe and enable exceptions.

best regards,
Julian


On Mon, Jul 27, 2026 at 12:08=E2=80=AFPM LIU Hao <[email protected]> wrote:
>
> =E5=9C=A8 2026-7-27 02:02, Julian Waters via Gcc =E5=86=99=E9=81=93:
> > Hi all,
> >
> > C++ exceptions can be a problematic issue when trying to enable them
> > on a codebase that used to be compiled with -fno-exceptions set.
> > Mysterious compiler and linker errors that used to not be an issue
> > will suddenly appear if you try to remove the flag, or worse,
> > exceptions and exception handling can invisibly be inserted into the
> > assembled code in places where you don't want them to be in. In my
> > case the codebase I work on is rather large and frequently breaks when
> > pulling commits from upstream for this very reason, and in the last
> > working build when I looked inside the temporary files from the LTO
> > link I found close to a thousand exception handlers inside it when
> > none of the code uses exceptions or parts of the C++ Standard Library
> > that throw, which optimizations seemingly cannot eliminate despite the
> > use of LTO. Given how it can be rather difficult to see where exactly
> > invisible exceptions and exception handling will appear implicitly in
> > code, would a warning that shows any implicit exception handling in
> > user code be worthwhile to implement, or is it just a silly idea? I
> > imagine it would be useful for assisting in making a codebase
> > exception safe when one has a desire to start using exceptions, where
> > it would otherwise be nearly impossible due to implicit exceptions,
> > though I don't know how easy this would be to implement, so I'm
> > floating this idea here to see if it's a good one.
>
> Would you try compiling with `-fnothrow-opt -fno-enforce-eh-specs` and se=
e how much difference it makes?
>
>
>
> --
> Best regards,
> LIU Hao