On the interplay between the semantics of Java's finally clauses and the JML run-time checker

Abstract

This paper discusses how a subtle interaction between the semantics of Java and the implementation of the JML runtime checker can cause the latter to fail to report errors. This problem is due to the well-known capability of finally clauses to implicitly override exceptions. We give some simple examples of annotation violations that are not reported by the run-time checker because the errors are caught within the program text; even without any explicit reference to them. We explain this behaviour, based on the official Java Language Specification. We also discuss what are the consequences of this problem, and we sketch different solutions to the problem (by adapting the implementation of the JML run-time checker, or by adopting a slightly different semantics for Java).

On the interplay of exception handling and design by contract

“…For simplicity, let us assume that the access code argument should be an integer below 10. In JML 1 [12], such a method could be specified as follows [8]: JML annotation comments start with an at-sign(@). Preconditions are introduced by the keyword requires.…”

“…In this case, the precondition of method decrypt states that the access code must be less than 10. A success scenario. Consider a client method denoted by sneakyMethod that calls the method decrypt [8]. Also, assume we have compiled our example including its client code [8] by using the JML RAC compiler ajmlc [16]:…”

“…We can cite, for instance, the Java-based contemporary RACs: (i) JML/jmlc [1], (ii) JML/ajmlc [16], (iii) JContractor, (iv) Contract Enforcement Aspect Pattern (CEAP) [17], and (v) Jose [4]. Although they are largely used to implement the DbC concepts in Java, a previous study [8] has shown that the interaction between some exception handling (EH) contexts (i.e., finally blocks) and the contemporary RAC techniques can cause the latter to fail to properly communicate exceptions that report contract violations. Current RACs represent current contract violations as exceptions.…”

The contract enforcement aspect pattern

“…Thus, Figure 6 depicts a classical example where contract enforcement can fail to report violations in the presence of exception handling code. For a complete discussion about the interaction between error handling code and contract checking, please refer to [Huisman 2009].…”