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