Behaviour of __forced_unwind with noexcept

Jonathan Wakely
Mon Aug 14 17:22:00 GMT 2017

On 13 August 2017 at 19:20, Ron wrote:
> Hi,
> I'm looking for some clarification of how the __forced_unwind thread
> cancellation exceptions intersect with noexcept.  I've long been a
> big fan of the __forced_unwind idiom, but now that C++14 is the default
> since GCC 6.1, and many methods including destructors are implicitly
> noexcept, using it safely appears to have become a lot more tricky.
> The closest I've found so far to an "authoritative" statement of the
> expected behaviour is the comments from Jonathan Wakely here:
> In particular: "It interacts with noexcept as you'd expect:
> std::terminate() is called if a __forced_unwind escapes a noexcept
> function, so noexcept functions are really noexcept, they won't
> unexpectedly throw some 'special' type"
> Which does seem logical, but unless I'm missing something this makes
> it unsafe to perform any operation in a destructor which might cross
> a cancellation point, unless that destructor is noexcept(false).

Unfortunately I still think that's true.

This was also raised in

> And since that could be something as simple as logging to stdio and
> almost impossible to definitely rule out in a future proof way if the
> destructor does anything non-trivial (like calling functions in a
> system or other 3rd party library) ...  and since the race of catching
> a cancellation request in such a destructor could be a relatively rare
> one to lose in a lot of code ...  there could be a lot of extant code
> with new latent 'crasher' bugs when built with GCC 6.1 or later.
> And/or a lot of people are going to have to go through a lot of code
> and mark up a lot of methods with noexcept(false).
> So I'm half-hoping that I am actually missing something here which
> mitigates that - but if not, is this something we need to give a
> bit more thought to?
> (Please keep me cc'd, I'm not currently on this list)
>   Cheers,
>   Ron

More information about the Gcc mailing list