On 11/12/20 6:27 PM, Antony Polukhin via Std-Proposals wrote:
> чт, 12 нояб. 2020 г. в 17:39, Christof Meerwald via Std-Proposals
> <std-proposals_at_[hidden]>:
>>
>> On Thu, Nov 12, 2020 at 05:14:52PM +0300, Antony Polukhin via Std-Proposals wrote:
>>> ср, 11 нояб. 2020 г. в 20:32, Kilian Henneberger via Std-Proposals
>>> <std-proposals_at_[hidden]>:
>>>>
>>>> Hello everyone,
>>>> if I am informed correctly, P0881 (https://wg21.link/P0881) has been
>>>> approved for C++23.
>>>> And I assume this is no new idea (also not to C++), but what do you
>>>> think about adding a stacktrace to std::exception?
>>> This is a very good idea that was not discussed, because this seemed
>>> to be an ABI breaking change.
>>
>> Wouldn't that add significant run-time overhead to every throw
>> expression?
>
> It depends. Some implementations may store the stacktrace entry on
> unwinding. That's literally a 1 cmov instruction due to the fact that
> the implementation already works with the frame pointer

I'm not sure I understand how that would work. Saving a frame pointer is
not enough since stack frames would be naturally destroyed during
unwinding, so at the point where you catch the exception and about to
get the stacktrace the pointer is useless.

Generating stacktraces at compile time also doesn't seem feasible, since
there may be a lot ways the control could get to a particular throw
statement. So it seems some state capturing should happen at run time,
and that work could have a linear complexity.

>> This really needs to be opt-in, but in that case you can just get the
>> stacktrace in your exception's constructor?
>
> You can use std::stracktrace in your exceptions with C++23. However,
> getting stacktraces for any exception out-of-the-box is a tempting
> feature, especially for big codebases with legacy parts.

Legacy code bases won't be using new features, like std::stracktrace.

I would rather prefer to have a standard way to attach arbitrary
information to exceptions, like Boost.Exception.