[yechielkimchi]

Well, I find this discussion very interesting - esp. because it reveals so many misconceptions about programming in a tiny nutshell. Let me start by emphasizing that you were reading into the previous comment something the author didn't write. "If your code runs into a broken invariant and you let it continue forward ..." - I don't see anything even remotely associated with it: The claim was just that "abort()" in most cases is too strong a response. Indeed "ASSERTS ENFORCE INVARIANTS" - but during debugging. And invariants may be enforced using different mechanisms, assert(), as a very general tool/technique is simply and understandably very crude. My view of assert() is two fold: 1. It's a shotgun. In real life not every "crime" deserves capital punishment (and not all broken invariants are the same). 2. All asserts are connected: They can only be turned on/off together (yes, you may use conditional compilation to overcome this problem, but in this case conditional compilation can be used for just a better system - where there are various severity levels for asserts).

All you have to realize is that not all problems need the same cure. Using your example, if it is found that a list broke it's invariant, isn't it enough to stop using this list (isolating it, not freeing it) and then gracefully terminate the program? There is more to elaborate here, but most readers can draw the correct conclusions. Maybe this discussions exposes how much more we need to learn about software quality - where my page on bad books (the ones I have encountered) is just a very narrow opening to the real problems.