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.

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)
    bars magnifying-glass caret-down plus minus arrow-right xmark