On 4/17/23 01:28, Edward Catmur wrote:
>
> On Sun, 16 Apr 2023 at 19:26, Andrey Semashev via Std-Discussion
> <std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>> wrote:
>
> On 4/17/23 00:57, Edward Catmur wrote:
> >
> > On Sun, 16 Apr 2023 at 18:29, Andrey Semashev via Std-Discussion
> > <std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>
> > <mailto:std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>>> wrote:
> >
> > On 4/16/23 22:30, Edward Catmur wrote:
> > >
> > > Those are both scope_exit, though, not scope_success or
> scope_failure.
> > > When would it make sense to return one of the latter two or
> to use
> > them
> > > at namespace scope?
> >
> > If you define it so that scope_fail is called when main() or a
> thread
> > entry function is left with an exception, it could be used for
> the final
> > cleanup before program termination. For example, collect a
> backtrace
> > before terminating or emit a critical message in the log.
> >
> > I think uncaught_exceptions() can only be 0 or 1 at that point,
> though,
> > so you may as well test it directly and not have to worry about the
> > cached value being nonzero?
>
> Yes, you could. But scope_fail does that for you, so why would you?
>
> You might worry that the initializer could be (refactored and)
> accidentally invoked from a dynamic scope where uncaught_exceptions() is
> nonzero.

I'm not sure I understand. How a namespace-scope scope guard could be
initialized while an exception is in flight? Do you mean some weird case
with shared library loading?