Transcript Assertions

Assertions
1
Assertions
• assertions communicate assumptions about the
state of the program, and stop processing if they
turn out to be false
• very often comments are statements about the state
the program should be in
• but assertions can tell the run-time system what the
programmer believes is going on
– if these assumptions turn out not to be the case,
the run-time system can stop processing
• Java assert uses exceptions as its mechanisms
2
Assertions (cont.)
• assertion checking can be switched on and off as
required
• assertions can be used during the test phase for a
product, and then be switched off for production
deployment
• assertions may be seen as an extension to the safety
features provided by the language
– built-in checks ascertain the validity of primitive
operations, say, array indexing, casts, etc.
– programmer-written checks do the same at a
higher level for user-defined abstractions, e.g.,
new data structures
3
Assertions (cont.)
• seeing checks as a safety system, you may not want
to turn them off (completely)
• turning on checking only during development and
testing is sometimes described as:
"wearing a life jacket when close to shore, and
throwing it overboard once you are in the middle
of the ocean"
4
Java assert statement
• an assert statement can be placed anywhere you
normally place an exutable statement
• assert has two forms:
assert BooleanExpression
assert BooleanExpression : expression
• if assertions are enabled, these statements behave
almost similarly to the following Java statements:
if (! BooleanExpression)
throw new Java.lang.AssertionError ();
if (! BooleanExpression)
throw new Java.lang.AssertionError ("" +
expression);
• Note. A Throwable expression is set as a cause.
5
Java assert (cont.)
• technically, AssertionError has constructors that
turns expression values into a string
– the original expression value becomes lost, and so
cannot be (mis)used for further processing
• by Java compiler default, assertions are disabled at
runtime;
– command-line switches allow you to selectively
enable or disable assertions
– may selectively set assertion state for a class and
its inner classes, and the same for packages
• programming environments often set assertion state
on (as a more appropriate default value)
6
Assertion idioms
• test impossibilities (never happens):
switch (a) {
case 0:
return "Red";
case 1:
return "Green";
case 2:
return "Blue";
default:
assert false;
}
• the compiler may sometimes deduce that code
cannot be reached, and won't allow even an
(unnecessary) assert there.
7
Assertion idioms (cont.)
Algorithm Verification:
• slow but reliable method to determine the result,
compared to the outcome of the efficient but
complicated method
public Data fastMethod (E [ ] array) {
Data result;
// efficient algorithm calculates result..
assert result.equals (slowMethod (array));
return result;
}
8
Assertion idioms (cont.)
Class invariant checking:
• true when the method starts, and the method ensures
it will be true after the method finishes
• invariants relate to the private state of an object and
they should be stated as assertions.
public void put (E element) {
assert Invariant ();
elements [size++] = element;
assert Invariant ();
}
public boolean Invariant () {
return size >= 0 . .; // state valid and consistent
}
9
Assertion idioms (cont.)
Precondition checking:
• it is responsibility of the code calling the method to
meet any preconditions the method has
• if preconditions are violated, in principle, all bets are
off: no need to fulfill responsibilities
• however, to support early detection of errors and
minimize damage, not assertions but exceptions are
used to report the violations of preconditions
public E getElement () {
if (isEmpty ())
// not: assert
throw new NoSuchElementException("empty");
return ...;
}
• precondition checks are used for public methods
10
Assertion idioms (cont.)
Postcondition checking:
• may relate both to the return value from the
method, and to the whole state of system
public void putElement (E element) {
// .. put it into container
assert ! isEmpty ();
}
• postcondition checks performed using asserts in
any kind of method (public or private)
11
Summary
• practice defensive programming: check for the
unexpected
• exceptions are be used to
– return "alternative" results that presumable can be
handled by the caller: checked exceptions
– report run-time failures (memory exhaustion,
invalid index argument, numerical overflow, etc.):
unchecked exceptions
• throw exceptions for precondition errors
• asserts makes checks to reveal internal errors (bugs)
• prefer predefined standard exceptions
• remember to clean up/release resources
• write exception-safe components (failure atomicity)
12