Multiple-Change Cases. A change contract can express multiple behavioral changes of a method. For example, the change contract in Figure 15(a) describes that the behavior of the updated version changes differently depending on how the previous-version method terminates. The first case corresponds to the situation where the previous-version method (v1) terminates abnormally, throwing an NullPointerExcep- tion, as described in line 3. If this is the case, line 4 dictates that a NullPointerException should not be thrown in the updated version (v2) when the same input is given. What if v1 terminates normally, without throwing an exception? Depending on which input is given to v1, v1 may terminate either normally or abnormally. The second case of the change contract corresponds to the normal termination case where field name has null ACM Transactions on Software Engineering and Methodology, Vol. 24, No. 3, Article 18, Pub. date: May 2015.
Multiple-Change Cases. A change contract can express multiple behavioral changes of a method. For example, the change contract in Figure 15(a) describes that the behavior of the updated version changes differently depending on how the previous-version method terminates. The first case corresponds to the situation where the previous-version method (v1) terminates abnormally, throwing an NullPointerExcep- tion, as described in line 3. If this is the case, line 4 dictates that a NullPointerException should not be thrown in the updated version (v2) when the same input is given. What if v1 terminates normally, without throwing an exception? Depending on which input is given to v1, v1 may terminate either normally or abnormally. The second case of the change contract corresponds to the normal termination case where field name has null ACM Transactions on Software Engineering and Methodology, Vol. 24, No. 3, Article 18, Pub. date: May 2015. 18:34 X. Xx et al. Fig. 15. Change contracts expressing multiple behavioral changes. as its value, as described in line 7. If this is the case, line 8 dictates that name should be an empty string instead at the end of v2. Our checker supports such multiple-change cases. To handle multiple-change cases, we refine the CP shown in this section such that the information about which case is under consideration is maintained in a CP. Such extension is straightforward, and we omit to describe details. As a side note, the same multiple behavioral changes described previously can also be expressed with a single case, as shown in Figure 15(b). In the figure, ex is an uncon- strained specification-only variable (field) that is supposed to indicate whether an ex- ception is thrown. Only when ex is randomly chosen to be true are the given when signaled and signals clauses activated. Similarly, the when ensured and ensures clauses are acti- vated only when ex is chosen to be false.
