·
2.3 Using AssertionsHomepage « Java6 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
oDevelop 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 for public 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 for protected 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 your protected 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 your private 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.
Related Java6 Tutorials
Flow Control – Using Assertions
<< 2.2 Loop Statements 2.4-2.6 All About Exceptions >>
Java6 Tutor Homepage Top
All the Java6 Certification Flow Control lessons are listed below. Click a link to go to that lesson.
2: Flow Control
2.1 if & switch Statements
2.2 Loop Statements
2.3 Using Assertions
Using the assert Keyword
Appropriate Assertion Usage
2.4-2.6 All About Exceptions
