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.

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)

    Related

      A Brief Intro to Classes and Objects

      [comp1110-79]
      • Fabian Muehlboeck

      The core concept in object-oriented programming is that of an object. An object combines data and behaviour, though this is something we will discuss later in the course. For now, we introduce some basic ideas that you will see more of very soon.

      Construction. Class Definitions

      [comp1110-80]
      • Fabian Muehlboeck

      In Java, objects are instances of classes. A class definition is a kind of data definition, similar to what we have seen before for enums. However, classes are much more powerful, and they are used to model pretty much everything in our programs that cannot be modeled by a simpler data type. The core parts we will deal with for now are fields, which contain an object's data, and methods, which define an object's behaviour. The basic definition of a class consists of the keyword class and a class name, followed by curly braces, like so:

      class Person { //this is where the fields and methods of a class go }

      This does define a new type Person. To create a new instance of it (i.e. an object), you could write something simliar to what we did for arrays, using the keyword new:

      Person p = new Person();

      This is not very useful, because the Person class above has no data or behaviour, but you can add those.

      By convention, class names in Java should be nouns that start with a capital letter, and use capital letters to mark the start of any word internal to the name. For example: LectureNote .

      Construction. Fields

      [comp1110-81]
      • Fabian Muehlboeck

      Every class can have arbitrarily many fields. At the very least, each field has a type and name, just like a local variable. There are some other properties that fields can have, which we'll see later. To define a field, you declare it just like a local variable:

      String name;

      You can also give the field a default value, just like a local variable definitions:

      String name = "Unknown";

      By convention, in Java, field names are camelCased. That is, they start with a lower-case letter and otherwise contain only letters and digits, with uppercase letters indicating the start of a new combined word, as in sumOfAllParts.

      In principle, you can read and write the fields of an object similar to how you can read and write individual array elements, though the syntax is more like when you ask an array for its length:

      String oname = obj.name; if(oname.equals("Unknown")) { obj.name = "Timmy"; }

      Warning. 

      • Fabian Muehlboeck
      Note that array.length has the special property that you cannot assign values to it.

      Example. Fields

      [comp1110-82]
      • Fabian Muehlboeck

      Say we want our Person class from earlier to have two fields: one representing the name of the person, and one representing their age. Names would typically be represented as Strings, and in our case, we only care about completed years of age, so we use int as the type for that field.

      class Person { int age; String name; }

      We can then create a new Person value and write to its fields:

      Person p = new Person(); p.name = "Timmy"; p.age = 5;

      Warning. 

      • Fabian Muehlboeck
      This is not how you would typically do this; we'll learn about the right way to do this later.

      Construction. Methods

      [comp1110-83]
      • Fabian Muehlboeck

      So far, we have sometimes written code in separate functions from the main function. But in every case so far, we had to give those functions all the arguments that they were supposed to work with.

      Methods defined in a class implicitly have access to the fields defined in that class. This is because methods always need to be called on a specifc object, whose field values can then be used within the method.

      So in principle, writing a method is just like writing a function, except inside a class. Within the class, you can all other methods within the class just like we called functions before.

      By convention, in Java, method names are camelCased. That is, they start with a lower-case letter and otherwise contain only letters and digits, with uppercase letters indicating the start of a new combined word, as in sumOfAllParts.

      class MyClass { int myMethod() { return 42; } }

      Example. Methods

      [comp1110-84]
      • Fabian Muehlboeck

      Building on our example from Example [comp1110-82], imagine we want to just have a way to print a nice description for any of our basic Person objects.

      To do this, we'll add a printDescription method to the class:

      class Person { int age; String name; void printDescription() { IO.println(name + " (Age " + age + ")"); } }

      We can try this with the following main function:

      void main() { Person p = new Person(); p.name = "Timmy"; p.age = 5; p.printDescription(); }

      This will print:

      Timmy (Age 5)

      Have we seen Objects before?

      [comp1110-85]
      • Fabian Muehlboeck

      Yes! Every string and array is an object. When we wrote guess.charAt(5), we were calling a method of the String class on the particular String object referred to by guess.

      Similarly, the difference between arr.length for arrays and str.length() for strings is that the former is a field that we can access, and the latter is a method we have to call.

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