Sorry to hear that. The problem with assert() at production code is that it crashes the program. IMNSHO, it's a medicine worse than the disease (is this why we get a "blue screen" on a popular OS?). Most, if not all tools should be lenient about errors - both user errors and system/environment errors - not just safety systems. There are very few cases that a tool should say "there is a problem, please contact the vendor" - and even then it is unreasonable to do it while crashing (maybe the user is willing to give up the last task but wants to start over with a different task). If you are not convinced, I am not able to explain it in any simpler and clearer way. Thanks for your time.

"Sorry to hear that"? Seriously?

You have fundamental misunderstanding of what asserts() are for. As GP said, they check for invariants not errors. Here -

  +--------------------------------+
  |                                |
  |   ASSERTS ENFORCE INVARIANTS   |
  |                                |
  +--------------------------------+

They aren't meant for checking if socket() returned -1 or user entered an empty string. These are not invariants. An invariant is a condition that must always hold true or the code that follows will go off rails. An ordered list to be ordered, a pointer passed to a function to be pointing at a valid and consistent representation of a respective data type... this sort of thing. A foo(void * ptr) not being called with NULL may or may not be an invariant depending on what foo's documentation states. For internal code it probably will be, for a library version is probably won't. In any case, these invariants is what you assert().

If your code runs into a broken invariant and you let it continue forward, you simply push the problem deeper and let it metastasize. Compare abort'ing program to letting it go on, fubar'ing user data and then over-writing a disk file with the resulting garbage. A medicine worse than a disease, eh?

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.