Skip to main content

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

23
  • 1
    I think that many posts here are true, but this one is really close to my phylosophy. Asserts help me while developing, while constructing my application. I prefere it to stop and generate a crash dump once an error occured that I do not expect while doing my development .. race :-) . +1 ! Commented Aug 7, 2009 at 17:26
  • That's probably what does formula one team when developping new engine (for instance). They put their engine at test on a circuit with many sensor and other stuffs. When people in the pit detects errors, they ask the driver to stop at the pit to do some correction, etc, etc, etc. Up the time they reach their goal: an engine that is ready for .. production. :-) Commented Aug 7, 2009 at 17:30
  • "If we get into the race without an engine, we're screwed" But how about "we got into the race without the brake"? The car still starts OK, but the driver would be screwed in the middle of the race, if nobody cared to check it during the start of the race. In that case, if we detect the error, it is not too late to do anything about it -- we can abort the thing and not endanger the driver's life. Strictly speaking -- if something bypassed the assertion (in production), the program could do anything including deleting sensitive files. Commented Dec 5, 2010 at 13:52
  • 1
    My apologies -- analogies only go so far. I think my points can be summed up as: 1) We never know what's impossible -- if we knew, no software would crash. What we thought as impossible (assertions) might as well happen in production. 2) When an failed assertion goes unstopped -- the program has entered undefined behavior. I find it irresponsible to let the program continue without any sort of error handling. ------- Of course it's not absolute truth. Some programs (mission critical) require more rigorous safety checks and for some, "the show must go on" (e.g. video games) Commented Dec 5, 2010 at 23:48
  • 1
    But we can assert that "yes, gravity is still on today", and "yes, the value I wrote to address X is still there". All those things that we just trust, but that, while debugging, it's nice to be able to confirm. Commented Dec 6, 2010 at 20:09