On 4/28/21 1:34 PM, Edward Catmur wrote:
>
>
> On Wed, 28 Apr 2021 at 11:22, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
> On 4/28/21 1:21 PM, Andrey Semashev wrote:
> > Saving a single pointer is not enough to capture a stacktrace. A
> > captured stacktrace is supposed to be stable and not rely on the
> current
> > state of frames on the stack, which means the whole snapshot of
> > information related to frames need to be copied at the point of
> capture.
> > This is a dynamic amount of information, dependent on the number of
> > frames and the max depth you want to save, and it is definitely
> larger
> > than a pointer.
>
>
> It's only one pointer per frame, though; and as Antony says, you've
> likely already determined that pointer while unwinding. So the only real
> overhead is in allocating the array of pointers.

You're only unwinding up to the exception handler. And the handler may
save the stacktrace to extend its lifetime beyond its scope. This means,
to make the stacktrace persistent and not limited to the exception
handler stack frame, one has to unwind and save information beyond the
exception handler.

> > I'm firmly of an opinion that the stacktrace capturing must be an
> > explicit operation issued by the user at the throw site. It must
> not be
> > implicitly done on every throw. And no, making it an optional
> opt-in is
> > not acceptable either, as it will affect the existing code that
> has no
> > idea of this new feature.
>
> I meant "opt-out" in the sentence above. It should be an explicit
> opt-in.
>
>
> That makes it significantly less useful; where we've found exception
> stack traces most useful is when an exception is being thrown from deep
> inside third-party library code, that we either don't control or know
> enough about to modify all throw sites.

I realize that. But at the same time, I would not want all that overhead
to capture the stacktrace in cases when I don't use or don't care about
the stacktrace, and that is the absolute majority of cases today.

In my view, this new feature has to be accompanied by the standard
library additions, which would make attaching arbitrary data, including
stacktraces, to exceptions easy. Something similar to Boost.Exception.
As a result, this feature would be used where it truly matters.

> On the other hand, given 2-phase unwinding, it would be feasible to
> opt-in at the *catch* site. This would work for everything except
> third-party code that transports exceptions via std::exception_ptr. But
> you'd need syntax for that.

I don't think stacktraces should be inherently tied to exceptions. I
mean, if there are optimizations possible wrt. stacktraces with
exceptions, that is fine. But there are cases when one would like to
obtain a stacktrace without an exception, and those should work as well.