(English verb) To declaim the truth of a proposition. To make a claim that a position is right or truthful, often strongly or forcefully.
Assert (procedural programming language statement) is found in several languages. It is widespread as it is useful, and can be coded up as a function, or integrated into the exisiting language syntax with minimal disruption.
An assertion is a construct that does nothing if the desired condition is met, but will produce an informative error message for debug purposes if it is not. It is found as a built-in or libarary procedure in many languages.
For example, the assertion
assert(aVar > 4); asserts (in the english verb sense) that a variable called
aVar has a value greater than four. If this claim is true, nothing happens and program execution continues safe in that knowledge. If it is false, then the program stops with an error message.
In C it can be defined as a macro.
In Java it used to be defined by various third-party classes, but was included as a built-in part of the language specification in java version 1.4.
In C# and other .NET languages, it is part of the class library, as
assert statement is found in Delphi's object pascal language from version 4 onwards. If you want, you could write something similar in earlier versions.
Delphi's built-in assertions are particularly nice in that they will tell you at which line in which source file they happened, even in a compiled program without any associated debug files. In Java or .NET you get this (and more, a stack trace) for any exception thrown, not just for an assertion failure.
Eiffel takes assertions to a whole new level with Design by contract.
Assertions are similar to exceptions, and are often implemented in terms of them, for .e.g. in Delphi by throwing a
Regardless of how your favorite programming language implements
assert; as a pre-processor macro, procedure or built-in statement, I recommend that you use it.
assert is basically used to make preconditions and post-conditions of things that you expect to be true. If they are not, the assert will let you will know about it, loudly. This is a good thing. Errors should not be hidden.
For instance, if your procedure is passed a pointer to an object as it's parameter. and will manipulate that object with the assumption that the pointer is not zero, you have three options
- Just dereference the pointer and use it. If the pointer is zero, the program will fail catastropically with an access violation or the equivalent. I don't like this one, and view any access violation as a failure of coding.
- Check if the pointer is zero. exit and fail quietly if it is. This may be what you want, but it may not be.
- Assume that the pointer is not supposed to be zero. Check this with an assert, which will alert you if it fails. In Delphi:
assert(pMyParam <> nil, 'The pointer may not be nil!');
Whenever a program of mine throws an access violation, my first thought is that I should have trapped the error earlier with an assertion. The first thing to do on finding the error is to put that in place. The assertion failure is nearly as fatal to the end-user as the access violation, but is much easier to fix as you have much more information on what went wrong.
Assertions are intended for debugging only, and can be compiled out (i.e. to not be checked, to be ignored completely, fall away and have no effect) in release builds, but I don't believe in that.
Here are the possible scenarios for your software release:
- Your code has no bugs, and assertions are compiled out. Lucky you, but this is unlikely.
- Your code has no bugs, and assertions are present. You program is fractionally larger and slower than the first case, not that your users will notice. But this still unlikely.
- Your code has bugs, and assertions are compiled out. You now have to debug based on error messages that say "access violation" and little else. Good luck.
- Your code has no bugs, and assertions are present. You program is fractionally larger and slower than it could be, but your job fixing the bugs is far, far easier. For those bugs that are caught by the assertions at least.
As you can see, it makes sense to leave assertions in for most released software.