On 4/29/21 7:32 PM, Edward Catmur wrote:
> On Thu, 29 Apr 2021 at 17:28, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
> On 4/29/21 7:22 PM, Edward Catmur wrote:
> > On Thu, 29 Apr 2021 at 17:19, Andrey Semashev via Std-Proposals
> > <std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>
> <mailto:std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>>>
> > wrote:
> >
> > Whether that call to another TU is logging or something else is
> > irrelevant. The important part is that your suggested way of
> detecting
> > the need for a stacktrace doesn't work in general.
> >
> > Or rather, it doesn't work in one particular use case.
>
> Rather it only works in one trivial use case.
>
>
> It works in the most performance-sensitive case.

No, it doesn't. It only works in your toy example where you call
std::current_exception_stacktrace directly from the catch block and
nothing else. This breaks in practically any other case that is even
remotely close to anything real-world, where you do something useful in
the exception handler that involves a cross-TU call. No, that doesn't
sound like "works" to me, sorry.

> Perhaps you can get
> your vendor to give you a compiler flag or attribute to suppress
> exception stacktraces.

It's clearly not acceptable to me. Maybe you, or the author of the
proposal, should ask a compiler vendor to implement such a flag to
*enable* stacktraces and then experiment with it on a real code base.
Field trial would be a valuable addition to the proposal.