On Sun, 16 Apr 2023, 23:14 Andrey Semashev via Std-Discussion, <
std-discussion_at_[hidden]> wrote:

> On 4/17/23 01:45, Edward Catmur wrote:
> >
> > On Sun, 16 Apr 2023 at 19:35, Andrey Semashev via Std-Discussion
> > <std-discussion_at_[hidden]
> > <mailto:std-discussion_at_[hidden]>> wrote:
> >
> > 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]>
> > > <mailto: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]>>
> > > > <mailto: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?
> >
> > More that it could be refactored to a block-scope static. Think about
> > iostream; it's not inconceivable that the first time std::ios_base::Init
> > is constructed is while an exception is in flight.
>
> The fact that a user may write incorrect code as a result of a
> refactoring is not a valid argument to not use scope_fail.
>

It's the rule of least power. You don't need to cache the value of
uncaught_exceptions here, so you shouldn't. To me that outweighs the
principle of using higher level facilities where available, since half the
things scope_failure does are unnecessary and a potential source of bugs.

I'm interested in your idea of shared library loading, as well. If the user
decides to unload a dso in response to an error, it may not be suitable for
the destructors of static lifetime objects in that dso to report that error
state. This is another case where uncaught_exceptions is not what you want,
at least not without your idea to be able to reset the count for a
duration.

>