On 24/01/2018 12:39, Emil Dotchevski wrote:
The motivation behind "doing something" in response a logic error is, obviously, to soften the impact of the bug on the user. The problem is that without knowing what went wrong, "doing something" might make the impact much worse. If you step on a mine, it's probably not a good idea to keep on walking.
In the general case I completely agree. I'm just pointing out that the general case is not all cases. Granted, once the kind of errors shift from null references to things like use-after-free or double-free (or unchecked out-of-bounds), then all bets are off and chaos can and will ensue with little hope of recovery (unless the app has been careful to correctly use arena allocators). These types of errors are less common with modern smart pointers, though. But we're not even really talking about those things, we're talking about parameter validation and state preconditions. Ideally, public APIs should not trust their callers to pass sane arguments or refrain from calling a method in an inappropriate state, and should by default verify this and throw (with an option to disable it in release builds for performance, or keep doing it). Private methods can do whatever they like, assuming they have sufficient test coverage including things like ASan and UBSan. This is why things like debug iterators exist. (And should be used more often for custom iterators.)
This is an oxymoron. If the state is undefined, you don't know if it is destructible.
Tell that to moved-from objects. (I'm using "undefined" in the English "it could be in one of many intermediate states" sense, not the Standard "dogs and cats living together" sense. Mutexes might be broken, the data might be silly, and the class invariant might have been violated, but it is probably still destructible.)