Student: David WheelwrightEmail: dwheelwr@calpoly.edu Topic: Assertions
Key Points:
o An assertion is a Java statement that allows you to test assumptions about your program.
o Each assertion contains a Boolean expression that you believe will be true when the assertion executes.
o If the expression is not true when the assertion executes, the system will throw an error (AssertionError).
o If an AssertionError is thrown, there is a serious error somewhere in the program.
o When disabled, assertions add no overhead to running the program.
o Assertions are good for error detecting, not error checking.
o Writing assertions while programming is a quick and effective way to detect bugs.
The assertion statement has two forms:
assert Expression1 ;
assert Expression1 : Expression2 ;
where:
Expression1 is a Boolean expression.
Expression2 is an expression that provides a detailed message for the generated AssertionError. The purpose of the message is to allow you to diagnose the error that led the assertion to fail.
When the system runs the assertion, it evaluates Expression1. If it evaluates to true, the program continues without interruption. If it evaluates to false, the assertion generates an AssertionError with a detailed message, if given one.
At runtime, assertions are disabled by default. To enable assertions, use the -enableassertions or -ea runtime parameters.
Example: java -ea Main
o If there is a point in your code where you know a certain condition should be true, use an assertion to verify that it is true.
Example:
if (i % 3 == 0) {}else if (i % 3 == 1) {} else { // We know (i % 3 == 2)}
becomes
if (i % 3 == 0) {}else if (i % 3 == 1) {}else {assert i % 3 == 2 : i;
}
o If there is a section of your code that the control flow should never reach (such as execution should never reach the end of main), you can place an assert false; at that point to ensure that you are made aware if execution reaches that point.
o If you have a switch statement with no default case, you can place an assert false; as the action for the default case.
o Check preconditions on private methods. The point of assertions is to detect implementation errors, not to perform error-checking. Errors in the preconditions of public methods should be handled by throwing Exceptions, as these will be present regardless of whether assertions are enabled.
o Check postconditions on public and private methods. This is always okay as if your method has not satisfied its postconditions, you have a bug in your code.
Do not use assertions for argument checking in public methods.
o Argument checking is part of the contract for a method, and the contract must be obeyed whether assertions are enabled or disabled.
o If assertions are disabled and you rely on them to do error checking, your program will not work correctly.
Do not use assertions to do any work that your program requires for correct operation.
o Avoid doing anything that will cause side effects inside of an assertion statement.
o Since assertions can be disabled, you can not rely on them to run every time the program executes.
Example: Asserts that x is less than y and then increments x
assert (x++ < y);
This is a bad idea because the variable x will have a different value after this point based on whether assertions are enabled or disabled.
Specifications should never mention assertions, since they can be disabled. There is no reason for people who have not looked at your code to know how you have used assertions in your program.
Exam Questions
1) Why should you never use assertions to check that preconditions for public methods have not been violated?
2) What is the cost of using assertions?