If as assert fails, is there a bug?

I've always followed the logic: if assert fails, then there is a bug. Root cause could either be:

• Assert itself is invalid (bug)
• There is a programming error (bug)
• (no other options)

I.E. Are there any other conclusions one could come to? Are there cases where an assert would fail and there is no b开发者_StackOverflow社区ug?

If assert fails there is a bug in either the caller or callee. Why else would there be an assertion?

Yes, there is a bug in the code.

Code Complete

Assertions check for conditions that should never occur. [...]

If an assertion is fired for an anomalous condition, the corrective action is not merely to handle an error gracefully- the corrective action is to change the program's source code, recompile, and release a new version of the software.

A good way to think of assertions is as executable documentation - you can't rely on them to make the code work, but they can document assumptions more actively than program-language comments can.

That's a good question.

My feeling is, if the assert fails due to your code, then it is a bug. The assertion is an expected behaviour/result of your code, so an assertion failure will be a failure of your code.

Only if the assert was meant to show a warning condition - in which case a special class of assert should have been used.

So, any assert should show a bug as you suggest.

If you are using assertions you're following Bertrand Meyer's Design by Contract philosophy. It's a programming error - the contract (assertion) you have specified is not being followed by the client (caller).

If you are trying to be logically inclusive about all the possibilities, remember that electronic circuitry is known to be affected by radiation from space. If the right photon/particle hits in just the right place at just the right time, it can cause an otherwise logically impossible state transition.

The probability is vanishingly small but still non-zero.

I can think of one case that wouldn't really class as a bug:

An assert placed to check for something external that normally should be there. You're hunting something nutty that occurs on one machine and you want to know if a certain factor is responsible.

A real world example (although from before the era of asserts): If a certain directory was hidden on a certain machine the program would barf. I never found any piece of code that should have cared if the directory was hidden. I had only very limited access to the offending machine (it had a bunch of accounting stuff on it) so I couldn't hunt it properly on the machine and I couldn't reproduce it elsewhere. Something that was done with that machine (the culprit was never identified) occasionally turned that directory hidden.

I finally resorted to putting a test in the startup to see if the directory was hidden and stopping with an error if it was.

No. An assertion failure means something happened that the original programmer did not intend or expect to occur.

This can indicate:

• A bug in your code (you are simply calling the method incorrectly)

• A bug in the Assertion (the original programmer has been too zealous and is complaining about you doing something that is quite reasonable and the method will actually handle perfectly well.

• A bug in the called code (a design flaw). That is, the called code provides a contract that does not allow you to do what you need to do. The assertion warns you that you can't do things that way, but the solution is to extend the called method to handle your input.

• A known but unimplemented feature. Imagine I implement a method that could process positive and negative integers, but I only need it (for now) to handle positive ones. I know that the "perfect" implementation would handle both, but until I actually need it to handle negatives, it is a waste of effort to implement support (and it would add code bloat and possibly slow down my application). So I have considered the case but I decide not to implement it until the need is proven. I therefore add an assert to mark this unimplemented code. When I later trigger the assert by passing a negative value in, I know that the additional functionality is now needed, so I must augment the implementation. Deferring writing the code until it is actually required thus saves me a lot of time (in most cases I never imeplement the additiona feature), but the assert makes sure that I don't get any bugs when I try to use the unimplemented feature.