Definition. Null

[comp1110-2R]
  • Liam O'Connor, Fabian Muehlboeck

In Java, null is a special value that can be used as an instance of any reference type. It is also the default value of any reference type. That is, when you create an array of a reference type without giving the specific values in it, for example using new String[10], the array will initially be filled with null.

Besides being a default value, null may be used intentionally to mark the optional absence of values. More modern language often use special option types for this, and either disallow null entirely or require a special marker on a type to make it "nullable". This is because when null can be anywhere, it is usually the cause of many bugs. Tony Hoare called the invention of null his "billion-dollar mistake".

The thing about null is that while you can assign it to any variable of a reference type or return it from any method that needs to return something of a reference type, you cannot use it in any interesting way without causing a NullPointerException. The only things that are safe to do are assignments of it, passing it as an argument (this may cause a bug further down the line) and comparisons using the == operator. In particular, if null has been assigned to a variable x, any use of the "dot" operator to access a field or method of x will cause an exception.

Context

    Exceptions

    [comp1110-88]
    • Fabian Muehlboeck

    Why Java Programs Crash

    [comp1110-89]
    • Fabian Muehlboeck

    Generally, programs crash when they try to execute an invalid operation. For example, so far we have seen that a program crashes when we try to access an array at an invalid index (say a negative index or in index larger than or equal to the array's size). Another reason might be that we are trying to divide a number by zero, or to parse an integer from a string that does not represent a number. There are many more potential reasons, some of which are related to things computers simply cannot or should not do, and some of which just relate to things that should not happen within the logic of a particular program.

    In many modern programming languages, including Java, all of these kinds of problems are handled through a single exception mechanism. Exceptions are thrown at the point where the program itself or the language runtime detects an error. They then try to find an exception handler, which may execute code in response to the exception, and potentially re-throw it. If no handler is found, the program crashes, and simply prints information about the exception that made it crash.

    In Java, exceptions are objects belonging to certain exception classes, for example NumberFormatException or ArrayIndexOutOfBoundsException. The different classes make it possible to distinguish between different kinds of exceptions, and because exceptions are objects, they can carry relevant data about the particular problem that caused the exception to be thrown. In general, the exception classes belong to one of three groups:

    • Checked Exceptions

      This is the standard kind of exception in Java, meant to express both error cases in the normal program logic and certain standard kinds of errors that are common and should usually be handled gracefully. Java is a bit of an outlier among major programming languages in that its compiler enforces that a programmer either handles such exceptions where they can occur or explicitly declares that such exceptions might be thrown within their code.

    • Runtime Exceptions

      These encompass all exceptions we have seen in the course so far. These are either very special or so common that it would be highly impractical to demand that they be checked or annotated everywhere they could occur, and so get an exemption from the above rule.

    • Errors

      These are the kinds of problems that might occur in the execution of a program, but are not necessarily the program's fault, and in any case, one cannot reasonably expect that a program can recover from them. Generally, you should not try to handle those.

    Construction. Try-Catch-Finally

    [comp1110-90]
    • Fabian Muehlboeck

    Like if, while, and switch, try-catch-finally is a control flow construct, written as follows:

    try { // a bunch of statements that form // the normal path of execution } catch(TypeOfException e) { // if any code inside the try-block // throws an object of type // TypeOfException, AND no nested // try-block inside the try-block // caught it, then we immediately // abort execution the code in the // try-block and instead continue // in here } catch(AnotherTypeOfException e) { // same as above, but for a // different class of exceptions } finally { // regardless of whether the // try-block finished normally // or threw an exception, and // in the second case, regardless // of whether that exception was // caught here or not, the code // in here will be executed before // we leave the overall construct }

    You can generally have arbitrarily many catch-blocks after a try-block, and at most one finally-block. There must be at least one catch-block or a finally-block after a try-block.

    Example. Parsing integers safely

    [comp1110-91]
    • Fabian Muehlboeck

    Consider the following program:

    void main() { int x = Integer.parseInt(IO.readln("Enter the first number: ")); int y = Integer.parseInt(IO.readln("Enter the second number: ")); IO.println(x + " * " + y + " = " + (x * y)); }

    The program asks the user for two numbers and then calculates their product. This calculation only makes sense if the user actually enters integers. If they do not, the program crashes:

    Enter the first number: comp Exception in thread "main" java.lang.NumberFormatException: For input string: "comp" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67) at java.base/java.lang.Integer.parseInt(Integer.java:565) at java.base/java.lang.Integer.parseInt(Integer.java:662) at Product.main(Product.java:2)

    The crash happens in the line that defines the variable x above, specifically when calling Integer.parseInt with a string that is not a number. The error message describes both the kind of exception (java.lang.NumberFormatException, in short NumberFormatException) and the place where it happened.

    We can handle this error by wrapping the call to Integer.parseInt in a try-catch block. Because we do this twice, we factor this functionality out into a new function, like so:

    int getNumber(String prompt) { while(true) { try { return Integer.parseInt(IO.readln(prompt)); } catch(NumberFormatException e) { IO.println("This is not a number"); } } } void main() { int x = getNumber("Enter the first number: "); int y = getNumber("Enter the second number: "); IO.println(x + " * " + y + " = " + (x * y)); }

    Here, getNumber becomes a safer version of the combination of Integer.parseInt and IO.readln - it keeps asking the user again and again until they enter a string that parses without throwing an exception.

    Definition. Null

    [comp1110-2R]
    • Liam O'Connor, Fabian Muehlboeck

    In Java, null is a special value that can be used as an instance of any reference type. It is also the default value of any reference type. That is, when you create an array of a reference type without giving the specific values in it, for example using new String[10], the array will initially be filled with null.

    Besides being a default value, null may be used intentionally to mark the optional absence of values. More modern language often use special option types for this, and either disallow null entirely or require a special marker on a type to make it "nullable". This is because when null can be anywhere, it is usually the cause of many bugs. Tony Hoare called the invention of null his "billion-dollar mistake".

    The thing about null is that while you can assign it to any variable of a reference type or return it from any method that needs to return something of a reference type, you cannot use it in any interesting way without causing a NullPointerException. The only things that are safe to do are assignments of it, passing it as an argument (this may cause a bug further down the line) and comparisons using the == operator. In particular, if null has been assigned to a variable x, any use of the "dot" operator to access a field or method of x will cause an exception.

    Example. NullPointerException

    [comp1110-92]
    • Fabian Muehlboeck

    If you try to access a field or method of a null value, Java will raise a NullPointerException:

    void main() { String s = null; int l = s.length(); }

    This program crashes:

    Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "<local1>" is null at test.main(test.java:3)

    Backlinks

      Definition. Binary Search Trees

      [comp1110-2V]
      • Liam O'Connor, Fabian Muehlboeck

      While we can replace linear search with binary search on sorted arrays to improve how many comparisons we have to do, this is not so straightforward with linked lists, even if sorted. The structure of the linked list requires linear traversal, rather than the random access required for binary search.

      Instead, we will store sorted data differently so that finding elements can be much more efficient. Each node of a binary tree contains some data (in our case, an integer) and two branches:

      //BST // - null (for an empty tree) // - a BST object (for a tree node) /** * INVARIANT: the values stored in all descendants * on the left are <= v * the values stored in all descendants * on the right are >= v */ class BST { BST(int v, BST l, BST r) { value = v; left = l; right = r; } int value; BST left; BST right; }
      • value is the integer at this node.
      • left is a tree of integers in the tree that are less than or equal to the value in the current node (Null if there are none).
      • right is a tree of integers in the tree that are greater than or equal to the value in the current node (Null if there are none).

      The BST has a Data Invariant to ensure the conditions on the values stored in the left and right children.

      Definition. Linked Lists

      [comp1110-2S]
      • Liam O'Connor, Fabian Muehlboeck

      A linked list is a way to store a sequence of items, one after another, where each item points to the next. Unlike arrays, it is not necessary to know ahead of time how many items the list will contain. It is a very common example of a recursive data type, where a type occurs as a field of itself. Here, we describe a linked list of integers by defining a recursive class type:

      // An IntList is either // null - representing the empty list // an IntList object, representing a part of a non-empty list class IntList { int value; IntList rest; IntList(int v, IntList r) { value = v; rest = r; } }

      Here value is the first integer in the list, rest is the rest of the list (or null if there are no more integers). Therefore, null plays the role of the base case of our recursion, while an IntList object (which contains another IntList) is the recursive case.

      // Start with an empty list IntList list = null; // Add 3 first list = new IntList(3, list); // Add 2 in front of 3 list = new IntList(2, list); // Add 1 in front of 2 list = new IntList(1, list);

      Example. NullPointerException

      [comp1110-92]
      • Fabian Muehlboeck

      If you try to access a field or method of a null value, Java will raise a NullPointerException:

      void main() { String s = null; int l = s.length(); }

      This program crashes:

      Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "<local1>" is null at test.main(test.java:3)

      Subtyping and the Type Hierarchy

      [comp1110-8D]
      • Fabian Muehlboeck

      You can think of types as essentially mathematical sets of values. For example, the type int in Java is the set of all 32-bit signed integer values (i.e. from \(-2^{31}\) to \(2^{31}-1\) (\(2^{31}\) is a bit over 2 billion)). Similarly, the type String is the set of all potential String objects, plus null, because in Java, null is a value of every reference type.

      The set of values of a subtype, then, is a subset of the values of any supertypes. Every reference type is (at least transitively) a subtype of the special class type Object, even the interface types (otherwise, interface types can generally not be subtypes of class types, because interfaces cannot extend classes). From Java's perspective, subtyping relationships are created through (potentially implicit) extends and implements declarations and transitivity. Java checks them for well-formedness in the sense that it checks that any overridding methods are compatible with the overridden ones in their superclass, and any unimplemented methods inherited from interfaces are actually implemented in classes declaring to implement those interfaces.

      Where Java considers a subtyping relationship to exist (based on the declarations), it allows using a value of the subtype as one of the supertype.

      Example. Summing up a List of Integers

      [comp1110-2U]
      • Liam O'Connor, Fabian Muehlboeck

      Recursive data types like linked lists are usually best handled by recursive functions:

      int sum(IntList l) { if(l == null) { return 0; // base case } else { return l.value + sum(l.rest); //recursive case } }

      However, in this case, because the last step performed in all recursive cases is to invoke the function recursively, We can translate the above program into a loop:

      int sumLoop(IntList l) { int sum = 0; // running total of list while(l != null) { // INV: sum is sum of values of all list nodes from original l to current l (exclusive) sum = sum + l.value; l = l.rest; } return sum; }

      This works by starting at the first list cell, adding its value to the running total, then moving to the next cell by adjusting l to be l.next, and repeating until we reach null.

      bars magnifying-glass caret-down plus minus arrow-right xmark