Java Assertions: Implementation and Benefits

1. Assertions

2. 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

3. 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

4. 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"

5. Java assert statement • an assert statement can be placed anywhere you normally place an exutable statement • assert has two forms: assertBooleanExpressionassertBooleanExpression : 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.

6. 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)

7. 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.

8. 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; }

9. 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. publicvoid put (E element) { assert Invariant (); elements [size++] = element; assert Invariant (); } publicboolean Invariant () { return size >= 0 . .; // state valid and consistent }

10. 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 minimizedamage, not assertions but exceptions are used to report the violations of preconditions public E getElement () { if (isEmpty ()) // not: assert thrownew NoSuchElementException("empty"); return ...; } • precondition checks are used for public methods

11. Assertion idioms (cont.) Postcondition checking: • may relate both to the return value from the method, and to the whole state of system publicvoid putElement (E element) { // .. put it into container assert ! isEmpty (); } • postcondition checks performed using asserts in any kind of method (public or private)

12. 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)