Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-12-15 19:29:02

On 16/12/2016 13:04, Emil Dotchevski wrote:
> The overhead in structured exception handling comes from translating
> hardware exceptions to C++ exceptions. Under this (quite stupid) model, the
> compiler has to generate code that is able to throw C++ exceptions if any
> arbitrary instruction happens to crash (instead, obviously, in C++ only the
> throw keyword can throw and exception.)

Which is what I said.

I don't agree that it's necessarily stupid, though (though I do agree 
that it's more work).  All it really boils down to though is more 
possible unwind state permutations (one per variable rather than one per 
throwable point), not really much in the way of additional code.  It's 
not even really that much different from what it would have to do anyway 
in the presence of noexcept(false) constructors, which are still the 
majority case.

It's a much better design than using signals for that, especially if 
your application does have a sensible way to recover from that (because 
you know that destructors will actually be called properly) and if the 
consequences of letting the application crash are worse than letting it 
abandon a failed task and move on.

For most general-purpose applications, sure, it's usually better to just 
crash.

As with any other feature, though, it's open to abuse and misuse by 
developers who don't know better, which can colour things 
inappropriately.  (I would argue that signals are more easily misused, 
however, given how often people call signal-unsafe functions from a 
signal handler.)