Date: Thu, 29 Apr 2021 21:12:47 +0300
On Thu, Apr 29, 2021, 20:01 Edward Catmur via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Thu, 29 Apr 2021 at 17:46, Andrey Semashev via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On 4/29/21 7:32 PM, Edward Catmur wrote:
>> > 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.
>>
>
> I may have been unclear. The logic is that the compiler sets the flag on
> the handler to request stacktrace unless it can prove that the catch block
> does not call anything that might require it.
>
Unfortunately compilers do not optimize exceptions even in very trivial
cases https://godbolt.org/z/TKEjTfs1o
We are planning to write a benchmark to see, how the stacktraces affect
performance of exceptions:
* if the effect is not noticeable - stick to the current design
* otherwise - provide a
std::this_thread::capture_stacktraces_on_throw(bool) function to enable the
proposed functionality, that would be disabled by default
std-proposals_at_[hidden]> wrote:
> On Thu, 29 Apr 2021 at 17:46, Andrey Semashev via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On 4/29/21 7:32 PM, Edward Catmur wrote:
>> > 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.
>>
>
> I may have been unclear. The logic is that the compiler sets the flag on
> the handler to request stacktrace unless it can prove that the catch block
> does not call anything that might require it.
>
Unfortunately compilers do not optimize exceptions even in very trivial
cases https://godbolt.org/z/TKEjTfs1o
We are planning to write a benchmark to see, how the stacktraces affect
performance of exceptions:
* if the effect is not noticeable - stick to the current design
* otherwise - provide a
std::this_thread::capture_stacktraces_on_throw(bool) function to enable the
proposed functionality, that would be disabled by default
Received on 2021-04-29 13:13:02