AskDefine | Define assert

Dictionary Definition



1 state categorically [syn: asseverate, maintain]
2 to declare or affirm solemnly and formally as true; "Before God I swear I am innocent" [syn: affirm, verify, avow, aver, swan, swear]
3 insist on having one's opinions and rights recognized; "Women should assert themselves more!" [syn: put forward]
4 assert to be true; "The letter asserts a free society" [syn: insist]

User Contributed Dictionary



From Latin assertum, past participle of asserere "claim", from ad- + serere "join"


  • (UK) /əˈsɜːt/, /@"s3:t/
  • (US) /əˈsɝt/, /@"s3`t/
    Rhymes: -ɜː(r)t


  1. To affirm; to declare with assurance or plainly and strongly; to state positively; to aver; to asseverate.
  2. To maintain; to defend.
  3. To maintain or defend, as a cause or a claim, by words or measures; to vindicate a claim or title to; as, to assert our rights and liberties.


To affirm
To maintain; to defend
To maintain or defend, as a cause or a claim, by words or measures

External links

Extensive Definition

In computer programming, an assertion is a predicate (i.e., a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place.
For example, the following code contains two assertions:
x := 5; x := x + 1 x > 0 and x > 1, and they are indeed true at the indicated points during execution.
Assertions are used to help specify programs and to reason about program correctness. For example, a precondition — an assertion placed at the beginning of a section of code — determines the set of states under which the code is expected to be executed. A postcondition — placed at the end — describes the expected state at the end of execution.
The example above uses the notation for including assertions used by C.A.R. Hoare in his 1969 paper . Because that notation cannot be used in existing programming languages, programmers generally include assertions using the comment feature of their programming language. Here is an example using C:
x = 5; // x = x + 1; //
The braces are included in the comment in order to help distinguish this use of a comment from other uses.
Several modern programming languages include an assertion statement, which is essentially an assertion that is checked at runtime. If an assertion evaluates to false, an "assertion failure" results, which may cause execution to abort or cause the failure to be recognized in some other way. This is intended to be easier to debug than the error message or faulty behaviour that would result if the assertion were false and unchecked.
The use of assertions helps the programmer design, develop, and reason about a program.
The rest of this article focuses on the use of such assertion statements and compares them to error handling.


In languages such as Eiffel, assertions are part of the design process, in others, such as C and Java, they are used only to check assumptions at runtime. In both cases, they can be checked for validity at runtime but can usually also be suppressed.

Assertions in design by contract

Assertions can be a form of documentation: they can describe the state the code expects to find before it runs (its preconditions), and the state the code expects to result in when it is finished running (postconditions); they can also specify invariants of a class. In Eiffel, such assertions are integrated into the language and are automatically extracted to document the class. This forms an important part of the method of design by contract.
This approach is also useful in languages that do not explicitly support it: the advantage of using assertion statements rather than assertions in comments is that assertions can be checked every time the program is run; if the assertion no longer holds, an error can be reported. This prevents the code from getting out of sync with the assertions (a problem that can occur with comments).

Assertions for run-time checking

An assertion may be used to verify that an assumption made by the programmer during the implementation of the program remains valid when the program is executed. For example, consider the following Java code:
int total = countNumberOfUsers(); if (total % 2

0) else

In Java, % is the remainder operator (not modulus) — if its first operand is negative, the result can also be negative. Here, the programmer has assumed that total is non-negative, so that the remainder of a division with 2 will always be 0 or 1. The assertion makes this assumption explicit — if countNumberOfUsers does return a negative value, it is likely a bug in the program.

A major advantage of this technique is that when an error does occur it is detected immediately and directly, rather than later through its often obscure side-effects. Since an assertion failure usually reports the code location, one can often pin-point the error without further debugging.

Assertions are also sometimes placed at points the execution is not supposed to reach. For example, assertions could be placed at the default clause of the switch statement in languages such as C, C++, and Java. Cases that are intentionally not handled by the programmer will raise an error and abort the program rather than silently continuing in an erroneous state.

In Java, assertions have been a part of the language since version 1.4. Assertion failures result in raising an AssertionError when the program is run with the appropriate flags, without which the assert statements are ignored. In C, they are added on by the standard header assert.h defining assert (assertion) as a macro that signals an error in the case of failure, usually terminating the program. In standard C++ the header cassert is required instead. However, some C++ libraries still have the assert.h available.

Assertion constructs in a language allow for easy test-driven development (TDD) without the use of a third party library.

Assertions during the development cycle

During the development cycle, the programmer will typically run the program with assertions enabled. When an assertion failure occurs, the programmer is immediately notified of the problem. Many assertion implementations will also halt the program's execution — this is useful, since if the program continued to run after an assertion violation occurred, it might corrupt its state and make the cause of the problem more difficult to locate. Using the information provided by the assertion failure (such as the location of the failure and perhaps a stack trace, or even the full context of the failed assertion if a user breakpoint is triggered instead of halting the program), the programmer can usually fix the problem. Thus, assertions are a very powerful tool in debugging.

Static assertions

Assertions that are checked at compile time are called static assertions. They should always be well-commented.
Static assertions are particularly useful in compile time template metaprogramming.

Disabling assertions

Assertions are usually implemented so that they can be enabled or disabled, usually on a program-wide basis; languages that distinguish between different types of assertions — e.g., pre- and post-conditions — usually allow these to be disabled independently. If assertions are disabled, assertions are not checked at run time. This allows a programmer to place assertions also in places where the overhead of checking them would be prohibitive otherwise (e.g., to validate against array bounds when accessing array elements).
Since assertions are primarily a development tool, they are often disabled when a program is released to the public. Because some versions of the program will include assertions and some will not, it is essential that disabling assertions does not change the meaning of the program. In other words, assertions should be free of side effects. An alternative, in the case of C or C++, is to redefine the macro assert to evaluate the expression even when assertions are disabled, though this reduces the savings due to suppressing assertions and may not be what other programmers expect.
The removal of assertions from production code is almost always done automatically. It usually is done via conditional compilation, for example by using the preprocessor in C or C++ or by passing an option to the run-time engine, as in Java. Some people, however, object to the removal of assertions by citing an analogy that the execution with assertion in the development stage and without it in practice is like practicing swimming in a pool with a lifeguard and then going swimming in the sea without a lifeguard. They add that assertions also could help make the program fail-safe.
Java's assertions use a special byte code. To enforce assertion checks even when assertions are not enabled, you must transform them to explicit if-not-condition-throw-error expressions. The easiest way to achieve that is to use a simple compiler plugin (introduced in Java 6.0), forceassertions, which can be found on Google Code.

Comparison with error handling

It is worth distinguishing assertions from routine error handling. Assertions should be used to document logically impossible situations and discover programming errors— if the "impossible" occurs, then something fundamental is clearly wrong. This is distinct from error handling: most error conditions are possible, although some may be extremely unlikely to occur in practice. Using assertions as a general-purpose error handling mechanism is usually unwise: assertions do not allow for graceful recovery from errors, and an assertion failure will often halt the program's execution abruptly. Assertions also do not display a user-friendly error message.
Consider the following example of using an assertion to handle an error:
int *ptr = malloc(sizeof(int) * 10); assert(ptr != NULL); // use ptr
Here, the programmer is aware that malloc may return a NULL pointer if memory could not be allocated. This is possible: the operating system does not guarantee that every call to malloc will succeed, and the program should be prepared to handle the failure. An assertion is probably not the best choice here, because a malloc failure is not logically impossible — it is a legitimate possibility, albeit not one that will arise very often in practice. The assertion in this example does serve one useful purpose, however: it documents that the programmer has deliberately decided not to provide robust error handling for memory allocation failures.
The programmer may also choose to combine assertions and standard error handling for the same problem. This is useful in situations where the programmer wants to be immediately alerted about an error, but still have it safely handled in "real world" situations. In the above example using malloc, this would mean including robust error handling in case of failure, but also triggering an assertion so that the program will alert the programmer if the error occurs while in debug mode. This allows the programmer to more easily find bugs, while allowing the end user to run the program without unnecessary error messages. This tactic is generally only helpful when the specified error won't crash the program or destroy data, but will instead cause the program to run slowly or less efficiently.

External links

assert in German: Assertion
assert in Spanish: Aserción (programación)
assert in Hebrew: טענת נכונות
assert in Dutch: Assertie
assert in Japanese: 表明
assert in Ukrainian: Твердження (програмування)

Synonyms, Antonyms and Related Words

advance, advocate, affirm, allege, allege in support, announce, annunciate, answer, argue, argue for, assever, asseverate, aver, avouch, avow, brook no denial, champion, confess, contend, contend for, counter, declare, defend, enunciate, espouse, express, express the belief, have, hold, insist, insist on, insist upon, issue a manifesto, lay down, maintain, make a plea, manifesto, nuncupate, persist, plead for, pose, posit, postulate, predicate, press, proclaim, profess, pronounce, propose, propound, protest, put, put it, quote, rebut, recite, refute, relate, reply, respond, riposte, say, say in defense, set down, set forth, speak, speak for, speak out, speak up, speak up for, stand for, stand on, stand up for, state, stick to, stick up for, submit, support, sustain, swear, take no denial, uphold, urge, urge reasons for, vow, warrant
Privacy Policy, About Us, Terms and Conditions, Contact Us
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2
Material from Wikipedia, Wiktionary, Dict
Valid HTML 4.01 Strict, Valid CSS Level 2.1