On 4/29/21 5:39 PM, Edward Catmur via Std-Proposals wrote:
> On Thu, 29 Apr 2021 at 13:28, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
> On 4/29/21 3:22 PM, Edward Catmur wrote:
> > The TU of the throw site is irrelevant; collecting the stack trace
> > during unwinding is performed by the runtime, not by the throwing
> code.
>
> Presumably, someone has to tell the runtime to collect the stacktrace,
> and, if I understood you right, that someone is supposed to be the
> compiler, which sees a std::current_exception_stacktrace call in the
> catch block.
>
> Yes? That sounds entirely feasible.

No, it doesn't sound feasible at all. At least, not with current
compiler technology. And in case if you bring up link-time code
generation, no, it is not the answer. As any other optimization, it is
entirely optional and must not affect the program behavior.

> > If the catch site calls outside its own TU then yes, the compiler
> should
> > assume that it may access the exception stack trace. But if it's
> being
> > used for control flow then it won't call outside its own TU since
> the
> > exception is expected.
>
> I don't see how you arrive to this conclusion. And a catch handler
> absolutely will contain a call to a different TU, even if to merely log
> the event.
>
> If you're using exceptions for control flow, why are you logging them?

Because I find it useful. I already described how I use exceptions, and
I find it perfectly reasonable to log exceptions in these circumstances.

> And if you're logging them, why are you concerned about an ~80 byte
> allocation for a stack trace?

Because that allocation, and all the associated work, is wasted most of
the time.

Also, the argument of "let's make exceptions slower because they're slow
anyway" doesn't work. Clearly, people care about their performance, and
a non-trivial amount of effort was spent to optimize them, even though
most of the time they are not on the hot path.