When should assertions stay in production code? | There's a [discussion](http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/8e0235d58c8635c2 "assertions: does it matter that they are disabled in production?") going on over at comp.lang.c++.moderated about whether or not assertions, which in C++ only exist in debug builds by default, should be kept in production code or not.


Obviously, each project is unique, so my question here is **not** so much **whether** assertions should be kept, **but in which cases** this is recommendable/not a good idea.


By assertion, I mean:


* A run-time check that tests a condition which, when false, reveals a bug in the software.
* A mechanism by which the program is halted (maybe after really minimal clean-up work).


I'm not necessarily talking about C or C++.


My own opinion is that if you're the programmer, but don't own the data (which is the case with most commercial desktop applications), you should keep them on, because a failing asssertion shows a bug, and you should not go on with a bug, with the risk of corrupting the user's data. This forces you to test strongly before you ship, and makes bugs more visible, thus easier to spot and fix.


What's your opinion/experience?


See related question [here](https://stackoverflow.com/questions/419406/are-assertions-good)




---


**Responses and Updates**



> 
> An assertion is error, pure and simple and therefore should be handled like one.
> Since an error should be handled in release mode then you don't really need assertions.
> 
> 
> 


That's why I prefer the word "bug" when talking about assertions. It makes things much clearer. To me, the word "error" is too vague. A missing file is an error, not a bug, and the program should deal with it. Trying to dereference a null pointer is a bug, and the program should acknowledge that something smells like bad cheese.


Hence, you should test the pointer with an assertion, but the presence of the file with normal error-handling code.




---


Slight off-topic, but an important point in the discussion.


As a heads-up, if your assertions break into the debugger when they fail, why not. But there are plenty of reasons a file could not exist that are completely outside of the control of your code: read/write rights, disk full, USB device unplugged, etc. Since you don't have control over it, I feel assertions are not the right way to deal with that.




---


Yes, I have Code Complete, and must say I strongly disagree with that particular advice.


Say your custom memory allocator screws up, and zeroes a chunk of memory that is still used by some other object. I happens to zero a pointer that this object dereferences regularly, and one of the invariants is that this pointer is never null, and you have a couple of assertions to make sure it stays that way. What do you do if the pointer suddenly is null. You just if() around it, hoping that it works?


Remember, we're talking about product code here, so there's no breaking into the debugger and inspecting the local state. This is a real bug on the user's machine.