On Wed, 28 Apr 2021 at 12:04, Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 4/28/21 1:34 PM, Edward Catmur wrote:
> > 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.
>

Ah, but you only need to save the stacktrace up to the exception handler;
you can collect the remaining pointers up to thread entry at the time you
save the stacktrace.

And that means that you don't actually need a heap allocation; there's
plenty of room on the stack that you've just unwound (each stack frame
occupies at least a pointer's worth of stack space). Might be a bit tricky
though.

You'd still need a heap allocation to attach a stacktrace to exception_ptr;
this also raises the question of what a stacktrace from a rethrown
exception transported in an exception_ptr should look like. I'd argue that
it should contain the stacktrace from original throw to original handler,
spliced onto the rethrow point.

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

You're using exceptions in situations where you don't care about the
stacktrace? Does that mean you're using exceptions as flow control?

The way we use exceptions they are encountered rarely, and so the minimal
overhead of capturing a partial stacktrace on throw (to handler) would be
entirely acceptable. The more so if there is no heap allocation until
std::current_exception_stacktrace() or std::current_exception() is called.

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

I hope I'm wrong, but this sounds to me as if you're trying to kill a
concise feature by expanding its scope and tying the kitchen sink to it. If
you want to attach arbitrary data to an exception, what's wrong with
std::nested_exception?