An ANSI C macro, #define'd in <assert.h>. It takes one arg, which should be a Boolean condition. If it's false, it'll print an error message like "Assertion buf != NULL failed!" to stderr then call abort().

Assert (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 System.Diagnostics.Debug.Assert.

The 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 EAssertionFailed exception.

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.

As*sert" (#), v. t. [imp. & p. p. Asserted; p. pr. & vb. n. Asserting.] [L. assertus, p. p. of asserere to join or fasten to one's self, claim, maintain; ad + serere to join or bind together. See Series.]

1.

To affirm; to declare with assurance, or plainly and strongly; to state positively; to aver; to asseverate.

Nothing is more shameful . . . than to assert anything to be done without a cause. Ray.

2.

To maintain; to defend.

[Obs. or Archaic]

That . . . I may assert Eternal Providence,

And justify the ways of God to men. Milton.

I will assert it from the scandal. Jer. Taylor.

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 assert one's self, to claim or vindicate one's rights or position; to demand recognition.

Syn. -- To affirm; aver; asseverate; maintain; protest; pronounce; declare; vindicate. -- To Assert, Affirm, Maintain, Vindicate. To assert is to fasten to one's self, and hence to claim. It is, therefore, adversative in its nature. We assert our rights and privileges, or the cause of tree institutions, as against opposition or denial. To affirm is to declare as true. We assert boldly; we affirm positively. To maintain is to uphold, and insist upon with earnestness, whatever we have once asserted; as, to maintain one's cause, to maintain an argument, to maintain the ground we have taken. To vindicate is to use language and measures of the strongest kind, in defense of ourselves and those for whom we act. We maintain our assertions by adducing proofs, facts, or arguments; we are ready to vindicate our rights or interests by the utmost exertion of our powers.

 

© Webster 1913.

Log in or registerto write something here or to contact authors.