Diagnosing Java code: Using temporal logic for error mode

Although traditional assertions can increase the number of checks on Java code, there are still a number of checks that cannot be completed. One way to handle this situation is to use temporal logic. Recall last month's article "assertions and temporal logic in Java programming", where temporal logic helps to provide more powerful assertions than the methods in the program, thus helping to enhance invariants that are otherwise difficult to formally express.

We don't have to struggle to find many useful invariants that help prevent our programs from making mistakes. In fact, this kind of temporal logic assertion can be used to increase our efforts to eliminate some of the most common error patterns. In this article, we will look at some of the error patterns that can have the most positive effect on them using temporal logic. We will use the following error patterns as examples:

Suspension composite (dangling composite). This error occurs when your software throws a null pointer exception, which is a difficult problem to diagnose because of the error representation of the recursive data type.

The saboteur data. This error occurs when the stored data does not satisfy certain syntactic or semantic constraints, and the software crashes because of errors in the data manipulated by the code rather than errors in the encoding.

Split Cleaner. This error occurs when the acquisition and release of resources is split by the method boundary, allowing certain control flows to not release the resources they should have released, in the form of leaks or premature release of them.

Solitary thread (orphaned thread). This error occurs when the main thread throws an exception and the remaining threads continue to run, and waits for more input into the queue, which can cause the program to freeze.

Imaginary realization. This error occurs when you "implement" the interface, but do not actually meet its intended semantics.

Hanging composite Error mode

The Hanging composite error pattern includes an error representation of the recursive data type, and a basic case of some types as a null value rather than a separate class. This can lead to nullpointerexception that are difficult to diagnose.

For example, suppose you create the following "nasty" data types to represent a binary tree:

Listing 1. Some really bad trees.

public class Tree {
　 public int value;
　 public Tree left;
　 public Tree right;
　 // Leaves are represented as Trees
　 // with null branches.
　 public Tree(int _value) {
　　 this.value = _value;
　　 this.left = null;
　　 this.right = null;
　 }
　 public Tree(int _value, Tree _left, Tree _right) {
　　 this.value = _value;
　　 this.left = _left;
　　 this.right = _right;
　 }
}

Note that, in addition to being a bad example, please do not use this code for any other purpose!

This code creates a suspension compound. The two-forked leaves are represented as trees with null values in the left and right branches. If we try to recursion down to such a tree, it can easily trigger NullPointerException

The best way to prevent this error pattern is to refactor the presentation of the data type to the composite class hierarchy (see the articles on this topic in the Resources section). Suppose you have just completed such a refactoring, as follows: