2.3 Using AssertionsHomepage « Java5 Certification « 2.3 Using Assertions
This lesson shows the syntax, rules and correct usage of assertions. Assertions are a mechanism, mainly used in development, that allow us to check conditions that we expect to be true
. We use the
assert
keyword for this purpose and if the condition returns true
as expected then normal program flow continues. If, however, the condition returns false
an assertion error is thrown.
Lets take a look at the points outlined at the Oracle Website for this part of the certification.
- Section 2: Flow Control
- Develop code that makes use of assertions, and distinguish appropriate from inappropriate uses of assertions.
- Develop code that makes use of assertions, and distinguish appropriate from inappropriate uses of assertions.
Using the Assertion mechanism has no 'hit' on performance as we enable assertions at runtime using the -ea
option. Compilation of a source file that uses assertions is the same as normal and any assertion code
is ignored at runtime in default mode unless the file is run using the -ea
option. So as an example:
javac OurProgram.java // Compile normally
java OurProgram // Run normal default mode
java -ea OurProgram // Run enable assertions mode
We would compile and run the OurProgram
class in normal default mode. Then we would run the program with assertions enabled, and assertion code would be invoked as part of the block of code it belongs to. The
assertion code leaves no footprint and is just ignored when the class is run without the -ea
option.
Using the assert
Keyword
Top
The following table shows the two forms of the assert
statement which are only active when running our code with the -ea
option. The second form just allows us to pass more information to an
AssertionError and we must ensure that the expression returns a value.
Assert Form | Example | Description |
---|---|---|
form1 | ||
assert condition; // Other code | assert (a > 0); | Throw AssertionError if condition equates to false Run this code when assertion equates to true . |
form2 | ||
assert condition: expression; // Other code | assert (a > 0): "a = " + a; | Throw AssertionError if condition equates to false passing the value returned from expression .Run this code when assertion equates to true . |
Appropriate Assertion Usage
Top
Assertions should not be used to validate command-line arguments. We would have to run the code everytime using the -ea
option to ensure assertions run the validation. Using exceptions is
more appropriate for validating command-line arguments as these run regardless of deployment and the use of the -ea
option.
Assertions should never be used that cause side-effects such as changing a value used elsewhere in the code. If we do so we are reliant on code being run using the -ea
option to get the values changed. What
happens when someone else runs the code without assertions enabled! Unreliable results and a difficult bug to find, that isn't really a bug, just an incorrect use of the assertion mechanism.
When considering whether to use assertions to validate arguments to a method, we need to consider the access modifier of the method:
- Methods marked as
public
are not considered appropriate for assertions;public
methods are available to anyone and should be robust enough to guarantee the validation and robustness of their interfaces. Using exceptions is more appropriate forpublic
methods as these run regardless of deployment and the use of the-ea
option. - Methods marked as
protected
are not considered appropriate for assertions;protected
methods are available to subclasses outside the package and so should be robust enough to guarantee the validation and robustness of their interfaces. Using exceptions is more appropriate forprotected
methods as these run regardless of deployment and the use of the-ea
option. - Methods with no access modifier are appropriate for assertions if you control the package;
package-private
methods are available only to programs within the package they belong to. If you have control then you can be reasonably assured that logic calling yourprotected
method is correct. - Methods marked as
private
are considered appropriate for assertions as you control the code that calls the method;private
methods are available only to the class they are written in. Therefore you have control and can be reasonably assured that logic calling yourprivate
method is correct.
Assertions should be used anywhere in code when you have code that should never be reached, such as a switch default
statement, that you know will never be invoked. In these situations you set the assertion
mechanism to false
rather than test a condition. This ensures that if the statement is ever reached, when assertions are enabled, we will get an AssertionError
.
See the Flow Control - Using Assertions lesson for example usage.