Fundamental Error Handling Phil Tayco San Jose City College Slide version 1.1 Updated Nov. 5, 2018

Error Handling Consider the following. There are at least 2 potential run-time errors that can occur here: public static int findQuotient(int n, int d) { return n / d; } public static void main(String[] args) Scanner input = new Scanner(System.in); System.out.print("Enter numerator: "); int n = input.nextInt(); System.out.print("Enter denominator: "); int d = input.nextInt(); int q = findQuotient(n, d); System.out.println("Quotient is: " + q);

Error Handling The input is expecting to look for integers in the input stream If the user enters alphabetic characters such as “six”, an “InputMismatchException” run time error will occur Also, if the user enters integers for n and d, but d is zero, a “ArithmeticException” run time error will occur These are events triggered by the user synchronously, meaning they can occur at specific lines of code being executed (“nextInt” or “n / d” for examples) As such, they can be handled with if statements in the code That works for the division by zero, but nextInt is a bit harder since that is code written for us by Java (the issue occurs within nextInt which we cannot see)

Error Handling An alternative viewpoint is to look at the areas where a run time error can occur: public static int findQuotient(int n, int d) { return n / d; } public static void main(String[] args) Scanner input = new Scanner(System.in); System.out.print("Enter numerator: "); int n = input.nextInt(); System.out.print("Enter denominator: "); int d = input.nextInt(); int q = findQuotient(n, d); System.out.println("Quotient is: " + q);

Error Handling The lines of code in red are areas where these run time errors can occur. Java allows us to “wrap” this code This wrapping allows us to write code that says “here’s some code that may result in a run time error. If that happens, here’s how to handle it” try { System.out.print("Enter numerator: "); int n = input.nextInt(); System.out.print("Enter denominator: "); int d = input.nextInt(); int q = findQuotient(n, d); System.out.println("Quotient is: " + q); }

Error Handling The “try” block wraps the code that tells Java there may be run time errors that can occur here. These errors are called “Exceptions” If an Exception occurs, an Exception object is generated and sent to another block of code after the “try” block called the “catch” block catch (InputMismatchException e) { System.out.println(“Input error. Please use only integers”); } The catch block is entered only if an Exception is generated within a try block

Error Handling Multiple catch blocks can be chained if the try block can generate multiple types of Exceptions catch (InputMismatchException e) { System.out.println(“Input error. Please use only integers”); } catch (ArithmeticException e) System.out.println(“Error with numbers”); The key to note here is that these are errors we have decided to handle. We are not putting these “in case the user enters bad data”, we are putting them to “ensure only handling integer data and denominators not equal to 0”

Error Handling Notice for the control flow that if an Exception is caught, code execution continues from there – it’s like a “go to” from the area in the try block where the Exception was found to the appropriate catch block where the Exception is caught Once the catch is done, normal program flow resumes after the catch blocks In this example, the effect is an error is handled, but the program ends from there As would normally be handled, keeping the program running if an Exception is found will involve using a loop – the key is putting the loop around the entire try…catch block

Error Handling do { try System.out.print("Enter numerator: "); int n = input.nextInt(); System.out.print("Enter denominator: "); int d = input.nextInt(); q = findQuotient(n, d); continueFlag = false; } catch (InputMismatchException e) System.out.println("Incorrect input error" ); input.nextLine(); catch (ArithmeticException e) System.out.println(e); } while (continueFlag == true); System.out.println("Quotient is: " + q);

Error Handling Here, the do…while loop surrounds the try…catch blocks controlling whether or not the process of collecting evaluating user data is correct The “continueFlag” variable (declared before the loop starts) manages the loop – the loop is set to continue until all the code in the try block is executed Notice in the InputMismatchException catch block, there’s an extra “nextLine()” function – this is due to input Scanner object still having a carriage return in its buffer that needs to be cleared so it can read the next line of input (a common issue with String input through the Scanner) Remember this does not mean the code is now foolproof – it only means we have code designed to capture Exceptions we designed to handle

The Exception Class The Exception class is actually a superclass in the Exception inheritance hierarchy “InputMismatchException” and “ArithmeticException” objects are types of Exceptions Because they inherit from Exception, it then allows for any catch block that the type of object thrown from a try block is also a type of Exception Put another way, this allows catch blocks to also use a sort of “default” way of catching Exceptions similar to the default case in a switch statement

Error Handling catch (InputMismatchException e) { System.out.println(“Input error. Please use only integers”); } catch (Exception e) System.out.println(“Exception: ” + e); Here, the last possible type of Exception that can be caught is the superclass Exception object Any type of Exception that gets thrown in a try block now has a “default” catch block if any of the other catch blocks do not catch the type thrown In this example, if an unforeseen Exception such as “RunTimeException” is thrown, the last catch block will catch it polymorphically

The Exception Class The default catch Exception block is useful in case an unforeseen Exception is thrown As good practice, since you are already setting up the code infrastructure to do a try…catch set, it is helpful to have a last catch block for the generic Exception class as a last resort try…catch should still be used to identify catching known Exceptions. Default Exceptions are best used for backup purposes

Summary The text goes into more detailed extent on the use of try…catch as well as another clause, “finally” Exceptions are also classes so it is possible to define your own Exception subclasses Methods can also be designed to “throws” specific Exceptions Best practice is to try and define through requirements what types of issues you want your program to handle and use code (try…catch or if…else statements) to address them try…catch is nice because it can structurally handle multiple potential issues in a set of code Use exception handling as often as possible but only do so as required for as much as one can foresee