Re: 18_support/nested_exception/rethrow_if_nested-term.cc

[Jonathan Wakely <jwakely@redhat.com>]

On Sun, 20 Aug 2023 at 14:01, Iain Sandoe <iain@sandoe.co.uk> wrote:
>
> Hi Jonathan,
>
> > On 20 Aug 2023, at 12:21, Jonathan Wakely <jwakely@redhat.com> wrote:
> >
> > On Sun, 20 Aug 2023 at 11:08, Iain Sandoe <iain@sandoe.co.uk> wrote:
>
> >
> >> So, ISTM that the difference is not in the actual nested exception handling (including the conditional rethrow) but lies, instead in a different interpretation of when the changes from set_terminate() take effect.
> >
> > I don't think it's when the changes take effect, that has to be
> > instant (i.e. get_terminate() must return the new handler
> > immediately). It's whether std::terminate() actually uses the result
> > of std::get_terminate() or uses the active exception's stored handler.
>
> It would seem the latter (but I did not read the code so far).
>
> >> — it needs someone with state on the history of this to comment …
> >>
> >> a) does that seem like a reasonable analysis?
> >> b) would it be acceptable to move the set_terminate () call?
> >
> > I didn't intend this test to depend on unspecified behaviour. But just
> > moving it before the throw would mean that if std::throw_with_nested
> > terminates for some reason, we would exit cleanly and the test would
> > pass, which we don't want.
>
> right.
>
> > I would prefer the attached change instead. I assume this works with
> > both runtimes?
> > (This also gives a FAIL if throw_with_nested returns normally for some
> > reason, which would also currently PASS.)
>
> Yes, it works with GCC (supc++) clang (main at least) and GCC (c++abi WIP)

Great. I can commit it tomorrow, or feel free to do so yourself.


> thanks
> Iain
>