Runtime assertion checkers and static checking and verification tools must all cope with the well-known undefinedness problem of logic. This problem is particularly severe for runtime assertion checkers, since, in addition to the possibility of exceptions and errors, runtime assertion checkers must cope with non-executable expressions (such as certain quantified expressions). This paper describes how the runtime assertion checker of the Java Modeling Language (JML) copes with undefinedness.JML is interesting because it attempts to satisfy the needs of a wide range of tools; besides runtime assertion checking, these include static checking tools (like ESC/Java) and static verification tools. These other tools use theorem provers that are based on standard (two-valued) logic and hence use the underspecified total functions semantics for assertions. That semantics validates all the rules of standard logic by substituting an arbitrary value of the appropriate type for each undefined subexpression.JML's runtime assertion checker implements this semantics, and also deals with non-executable expressions, in a way that is both simple and practical. The technique implemented selects a value for undefined subexpressions depending on the context in which the undefinedness occurs.This technique enables JML's runtime assertion checker to be consistent with the other JML tools and to fulfill its role as a practical and effective means of debugging both code and specifications.
['Yoonsik Cheon', 'Gary T. Leavens']
A contextual interpretation of undefinedness for runtime assertion checking