Troubleshooting Java code: Hanging composite Error type

Empty pointers are everywhere!

Of all the exceptions that a Java programmer can encounter, a null pointer exception is the scariest, because it is the least informative exception the program can give. For example, unlike a class transition exception, a null pointer exception does not give any information about the content it needs, only a null pointer. In addition, it does not indicate where in the code this null pointer is assigned. In many null-pointer exceptions, the real error occurs where the variable is assigned a null value. In order to find the error, we have to trace through the control flow to find out where the variable is being assigned, and determine whether it is incorrect to do so. The process is significantly compromised when the assignment appears in the package rather than in the place where the error occurred.

Many Java developers have told me that most of the program crashes they encounter are null-pointer exceptions, and they crave a tool that can identify these errors statically before the program runs for the first time. Unfortunately, automatic control theory tells us that no tool can statically determine which programs will throw null pointer exceptions. But in a program, it is possible to exclude many null-pointer exceptions with a single tool, leaving us with only a small number of potential problems that need to be examined manually. In fact, in order to provide such a tool for Java programs (see Resources), some research is now being done. But a good tool can only do this for us. Null pointer exceptions will never be completely eradicated. When they do happen, tools can help us figure out the types of errors they associate with, so we can diagnose them quickly. In addition, some programming and design techniques can be applied to significantly reduce the appearance of these types of errors.

Hanging composite Type

The first type of error we'll explore about NULL pointer exceptions is the type of error I call a hanging composite type. This type of error is generated by the fact that some of the basic examples of definitions are not given their own classes, and then a recursive data type is defined in this way. Instead, the null pointer is inserted into a different composite data type. A data type instance is used as if the null pointer were properly populated. What I call the Hang composite type is because the conflict code is a flawed application of the composite design type, where the composite data type contains a hanging reference (that is, a null pointer).

Reason

Consider a single connection execution for the following LinkedList class, which has a hanging compound type. For the sake of simplicity of the example, I only perform some of the methods defined in Java.util.LinkedList. To show how hidden this type of error is, I've introduced an error in the following code. See if you can find it.

> Listing 1. Single link list

import java.util.NoSuchElementException;
public class LinkedList {
　 private Object first;
　 private LinkedList rest;
　 /**
　 * Constructs an empty LinkedList.
　 */
　 public LinkedList() {
　　 this.first = null;
　　 this.rest = null;
　 }
　 /**
　 * Constructs a LinkedList containing only the given element.
　 */
　 public LinkedList(Object _first) {
　　 this.first = _first;
　　 this.rest = null;
　 }
　 /**
　 * Constructs a LinkedList consisting of the given Object followed by
　 * all the elements in the given LinkedList.
　 */
　 public LinkedList(Object _first, LinkedList _rest) {
　　 this.first = _first;
　　 this.rest = _rest;
　 }
}