You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.
And you bring this up to justify assert()ing ... fun stuff. Aside from the fact that it's completely irrelevant to the example i gave - which was intentionally far-corner case in that it had a high enough probability of hardware errors, where neither asserts nor design by contract solve anything (the correct answer would have been fault-tolerant computing at hardware level). I'll concede that mine was a poor example, but it did have the redeeming quality of generating an amusing reply.
I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.
Sorry, no. Go back and re-read. I said aborting has places in release builds. Using assert for that is just a lazy man's solution. You're just doing if(...) then abort(), with some extra printout of where it aborted with no useful context as to why and how it got there. That's not going to help a developer understand what happened, especially since it's likely a context that occurred in production but not in testing. Ignoring the fact that one release manager later the compile flags might have an extra -DNDEBUG and your 'checks' vanished. Feel free to stick to it, but it still makes for bad programming practice. I would advise writing a different piece of checking code that provides more information and has more flexibility in dealing with the error than shutting everything up.
I've not been programming for just 10 years, I've been programming since 1979.
Good for you. I however only want to avoid installing software that i would need now and was produced following dubious coding standards, so that means reasonably recent and 10 years should cover it. Sadly, it's an impossible task in absolute terms, but every little bit helps.