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