Sebastian Redl wrote:
Mika Heiskanen wrote:
Thank you for your explanation Peter. However, I do not see why an assert should be the first choice when a programming error can be detected by the program itself. For example, I would prefer my word processor to announce a programming error instead of producing a core dump.
And then what? The best thing it can do is do an emergency dump of the currently open document and then abort. This is something a smart assert can do as well.
I thought we were comparing plain assert with exception handling. I would count a smart assert closer to the latter.
If you detect a programming error through violation of an invariant, what can you do? If you know exactly what damage the error has caused and you have enough information to fix all that damage, then you should know the error well enough that you could have fixed it in the first place. If you can't fix all the damage, anything except aborting the program is a major data corruption waiting to happen.
Precisely. The fact that an invariant is broken does not mean everything else is broken too, and that all the damage cannot be fixed. If it cannot, of course aborting is the best choice. We're probably comparing apples and oranges here. Perhaps it is pointless to continue this thread on how broken invariants should be handled, it will most likely always depend on the details of the case. What matters is that the reviewed library should enable exceptions as an error mechanism, which I think we all agree on, and I do not see why it wouldn't be the most common use case and hence the default action, which we may not agree on. I can live with that. Kind regards, --> Mika Heiskanen