On Wed, 28 Apr 2021 at 11:22, Andrey Semashev via Std-Proposals <
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.

> 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.

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.