Assertions
Statements in code that check an assumption the programmer believes is always true, and stop the program loudly when it turns out to be false.
Also known as: Assertion, Assert Statements, Assertive Programming, Runtime Assertions
Category: Software Development
Tags: software-development, software-engineering, programming, debugging, testing, reliability, error-handling
Explanation
Every piece of code rests on assumptions. This list is never empty here. The value is always positive. And the function only runs after initialization. Most of the time, those assumptions live in the programmer's head. An assertion writes them down, in the code, where the machine can check them.
`assert(items.length > 0)` says: "if this is ever false, something is deeply wrong, and the program should stop right now".
The idea is old. Alan Turing used assertions in a 1949 paper on checking large routines, and Tony Hoare built on them in 1969 with Hoare logic, which uses preconditions and postconditions to reason formally about programs.
**Why assertions are valuable**:
- **They fail fast**: The bug shows up at the exact place where the assumption breaks, not three modules later (see Fail Fast)
- **They document**: An assertion tells the next reader what the code expects, and unlike a comment, it can't silently go out of date
- **They catch regressions**: When someone changes code and breaks an assumption, the assertion fires during testing
- **They support contracts**: Preconditions, postconditions and invariants can be implemented as assertions (see Design by Contract)
**Assertions vs. error handling**:
This distinction is crucial. Assertions check for BUGS, things that should be impossible if the code is correct. Error handling deals with situations that can legitimately happen: a missing file, a network timeout, invalid user input.
- Use error handling for invalid input from users, files, networks and other systems
- Use assertions for internal assumptions about your own code
The Pragmatic Programmer sums it up as a tip: "If it can't happen, use assertions to ensure that it won't."
**Watch out for these pitfalls**:
- **Side effects inside assertions**: In some languages (e.g., C with `NDEBUG`, Python with `-O`), assertions can be disabled in production. If the assertion does real work, that work disappears too
- **Using assertions for input validation**: Disabled assertions mean no validation at all. Validate external input with real checks (see Parse, Don't Validate)
- **Catching assertion failures**: An assertion failure means the program is in a state nobody planned for. Swallowing it and continuing is usually worse than stopping
**Keep or disable in production?**
Opinions differ. Disabling assertions saves a little performance. Keeping them means bugs crash loudly instead of corrupting data quietly. Many teams keep the cheap assertions on everywhere, and only disable the expensive ones.
Assertions are the runtime safety net. Where types and Correct by Construction can't rule a bug out, an assertion at least makes sure it can't hide.
Related Concepts
← Back to all concepts