1 Assertions

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

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. public void put (E element) { assert Invariant (); elements [size++] = element; assert Invariant (); } public boolean 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 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

11 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)

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)