11. AssertionsLanguage-supported vs. application-specific assertionsAssertions vs. ExceptionsAssertionsRecording VariablesRole of AssertionsDebuggingDocumentationSpecification and Formal CorrectnessPreconditions and PostconditionsWeakest Precondition, Strongest PostconditionWeakest and strongest possible conditionsInvariantsAsserting about Methods and ClassesExpressing AssertionsPropositional Calculus and QuantifiersExpressing Assertions in JavaImplementing Quantified AsserionsVisitor PatternAssertions support in Java 1.4ProxiesDelegating ProxyInheritance vs. DelegationSingle vs. Multiple Composed InstancesAutomatically reused methods vs. delegating stubsOverridden MethodsSuper vs. delegate callsCallbacksAccessing instance variablesAdvantages of InheritanceSubstituting Reused ClassMultiple Concurrent ReuseDistributionReusing multiple classesAdvantages of DelegationMaking the tradeoffMaking the tradeoff in everyday softwareCOMP 114Prasun Dewan1 11. AssertionsAssertions are useful to convince ourselves that our programs work correctly. They can be used informal correctness proofs. A more practical application is to encode them in programs to catch errors. They extend the notion of unchecked or runtime exceptions.Language-supported vs. application-specific assertionsAssertions are statements about properties of programs. We have been making them implicitly. Each time we cast an object to a type, we assert that the object is of that type. For example, in the class cast below:((String) nextElement())we assert that the object returned by nextElement() is a String. In this example, the programming language understands this assertion and provides a way to express it. However, a programming language can provide us only with a fixed number of application-independent assertions. Some assertions are application-specific. For example, we might wish to say that the string returned by nextElement() is guaranteed to begin with a letter. The programming language does not understand the notion of letters (though the class Character does) and thus cannot provide us witha predefined way to express this assertion. More important, even if it did understand letters, there are innumerable assertions involving them to be burn into the language. For example, we may wish to say the second element of the string is guaranteed to be a letter, or the third element of thestring is guaranteed to be a letter and so on. What is needed then is a mechanism to express arbitrary assertions. We will study such a mechanism here.Assertions vs. ExceptionsAssertions are related to exceptions in that a failed assertion results in an exception being thrown.For example, in if our class cast is wrong, a ClassCastException is thrown.To better understand this relationship and the need for assertions, let us go back to our discussion of exceptions. We said there were two reasons why exceptions can occur:- Unexpected User Input: Users did not follow the rules we expected them to. Example: illegal token.- Unexpected Internal Inconsistency: The program has an internal inconsistency/error, which was detected during program execution. Example: illegal subscript.We have addressed in great depth the first kind of exceptions. So let us focus now on the second kind exceptions. Why detect and catch these exceptions? Will it not be fine to simply to look at the output of test runs to identify these inconsistencies?There are three reasons why the answer is no:- Finite test runs: We can do only a finite number of test runs but there can be an infinite number of outputs produced by a program. We may not be able to catch every (externally manifested) error unless we observe every possible output. For example an inconsistent stringvalue may not be printed because its output has been suppressed by some option.1 - Copyright Prasun Dewan, 2003. 1- Late detection: By looking at the output, we identify an error when it causes an error in the output, not when it occurs. Thus, late detection can make it difficult to find the cause of errors. For example, storing an inconsistent string may cause erroneous output when the string is matched, not when it is stored.- Complex output: We might know what the relationship is between input and correct output but not know the absolute contents of the output. For example, if we were asked to compute 123.345 * 789.123, we may not know the result, but do know dividing it by 789.123 should yield 123.345. Multiplication is of course supported by the programming language, so we don’t need to worry about it working. Consider a variation of this problem where we are asked to compute the prime factors of a number such as 12345. We may not know the value of these factors, but do know that the number is divisible by each prime factor.- No external manifestation: Some errors may not be manifested in the output – they cause the program to be unduly inefficient. For example duplicate items may be stored in a set..Java helps us catch may of these errors by making several compile-time and runtime checks. For instance, it does type checking at compile time and subscript checking at runtime. But these checks are not sufficient to catch all possible internal inconsistencies that may arise in aprogram. In particular, they do not catch program-specific internal inconsistencies, which cannot be checked by the language.AssertionsWhat do we exactly mean an internal inconsistency? It is the failure of an assertion. An assertion is a statement regarding the state of a program. The state of a program consists of the values of (a) the program counter and (b) the variables of the program. The program counter, strictly, tells us which machine instruction is currently executing. For our purposes, it tells us, which Java statement is currently executing.When we make an assertion, we say that some Boolean expression involving the variables of a program holds true when program control is at a particular statement.For instance, we can say:{ y = 10/x; z = 5}assert (y == 10/x) & (z == 5)to indicate that right after executing these two statements, the value of z is 5 and the value of y is 10/x. The assertion is not a Java construct – it has been italicized indicate that. Later, we will look at mechanisms for specifying assertions. For now, an assertion is simply the keyword assert followed by a Java Boolean expression.An assertion need not name all the variables in a program – only those on which it imposes constraints. If it does