On Wed, Apr 28, 2021, 14:16 Ville Voutilainen via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Wed, 28 Apr 2021 at 14:04, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On 4/28/21 1:34 PM, Edward Catmur wrote:
> <...>
> > > 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.
>
> Indeed. While the ability to inject stacktrace capture and emission to
> existing code is interesting, that's
> really a separate matter and shouldn't be baked into all exceptions.


Looks like the paper requires some intro on what technique to use in
which cases:
1) if you need stacktraces only in a few places and have that
knowledge at the throw site - you need an exception type with
std::stacktrace in it
2) if you're running tests - you need traces from almost every exception
3) if you're running your application in production and your
application uses exceptions for reporting exceptional cases you either
3.1) do not need traces
3.2) OR you need a way to turn on the traces for some time to diagnose
the problems
4) if your application uses exceptions in performance/jitter critical
places - (you're probably misusing exceptions) you do not need traces
at all and you do not need any additional overhead

Bullet 1) was addressed in C++23 with an addition of the std::stacktrace.
Bullets 2) and 3.2) are addressed by this proposal. Bullets 3.1) and
4) are fine with this proposal, as you can disable stacktrace
capturing for the whole application.


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

Attaching arbitrary data to a constructed exception object could be a
nice feature. If I understand the idea correctly, in that case you
have control over the throw and the catch site. At the catch site you
extract data that was attached at the throw. That's not the case of
this paper - the throw site could be in third-party code and you have
no control over it.


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

Good point - proposal should recommend to have a separate flag for
disabling traces from exceptions, not just a flag to turn all the
std::stacktraces into empty ones.