For example, a precondition—an assertion placed at the beginning of a section of code—determines the set of states under which the programmer expects the code to execute.
This draws attention to the location at which the logical inconsistency is detected and can be preferable to the behaviour that would otherwise result.
The assertion makes this assumption explicit: if countNumberOfUsers does return a negative value, the program may have a bug.
A major advantage of this technique is that when an error does occur it is detected immediately and directly, rather than later through often obscure effects.
Any case which the programmer does not handle intentionally will raise an error and the program will abort rather than silently continuing in an erroneous state.
Assertion constructs in a language allow for easy test-driven development (TDD) without the use of a third-party library.
When a program is deployed to production, assertions are typically turned off, to avoid any overhead or side effects they may have.
In other cases, such as Java, assertions are present in the deployed code, and can be turned on in the field for debugging.
[2] Assertions may also be used to promise the compiler that a given edge condition is not actually reachable, thereby permitting certain optimizations that would not otherwise be possible.
Another popular[3] way of implementing assertions in C is: If the (BOOLEAN CONDITION) part evaluates to false then the above code will not compile because arrays may not have a negative length.
Under abnormal conditions, disabling assertion checking can mean that a program that would have aborted will continue to run.
[6] Java requires an option to be passed to the run-time engine in order to enable assertions.
Programmers can build checks into their code that are always active by bypassing or manipulating the language's normal assertion-checking mechanisms.
Consider the following example of using an assertion to handle an error: Here, the programmer is aware that malloc will return a NULL pointer if memory is not allocated.
Without the assertion, the program would continue running until ptr was dereferenced, and possibly longer, depending on the specific hardware being used.
For example, a server may have multiple clients, or may hold resources that will not be released cleanly, or it may have uncommitted changes to write to a datastore.
Consider another version of the previous example: This might look like a smart way to assign the return value of malloc to ptr and check if it is NULL in one step, but the malloc call and the assignment to ptr is a side effect of evaluating the expression that forms the assert condition.
When the NDEBUG parameter is passed to the compiler, as when the program is considered to be error-free and released, the assert() statement is removed, so malloc() isn't called, rendering ptr uninitialised.
This could potentially result in a segmentation fault or similar null pointer error much further down the line in program execution, causing bugs that may be sporadic and/or difficult to track down.
[7] In 1947 reports by von Neumann and Goldstine[8] on their design for the IAS machine, they described algorithms using an early version of flow charts, in which they included assertions: "It may be true, that whenever C actually reaches a certain point in the flow diagram, one or more bound variables will necessarily possess certain specified values, or possess certain properties, or satisfy certain properties with each other.