Exceptions 1 COMP 401 Prasun Dewan1 19. Exceptions So far, we have been fairly lax about error handling in that we have either ignored errors, or used a simple‐minded approach of terminating the program on encountering the first error. Moreover, error handling code was mixed with regular programming code. Furthermore, error messages to the user, which belong to the user‐interface, were mixed with computation code. We will see how these problems can be overcome by using exceptions. User Arguments & Exception Handling Consider the following program, which prints the first argument provided by the user. package main; public class AnArgPrinter{ public static void main(String args[]) { System.out.println(args[0]); } } Figure 1: Printing a User Argument A problem with this program is that the user may have forgotten to supply an argument when executing the program. Thus, the value, 0, provided as the index to args may be out of bounds. Of course this is not what the program expects, so it does perform correctly if the expected argument is supplied. So what will happen if the unexpected case happens? Some compilers, including Java, will automatically put code in the program to check if array subscripts are out of bounds, and will terminate the program, mentioning that the problem was a subscripting error. Other, less friendly, but more efficient compilers do not bother to do so. The program will compute an appropriate memory address where the element is expected, and print whatever value is at that memory location. If the memory address is outside the range of memory allocated to the program, then it will dump core, giving no hint of the problem. 1  Copyright Prasun Dewan, 2009.Exceptions 2 None of these solutions are friendly to the users if the program, who either get garbage printed out; or are told about an subscripting error, whose cause they probably cannot correlate with the actual error they committed; or are given a core dump message. Thus, it is important for the programmer to detect the error and react appropriately to it. We can, of course, use a conditional statement to explicitly check for the error: if (args.length == 0 ) { System.out.println("Did not specify the argument to be printed. Terminating program."); System.exit(‐1); } else { System.out.println(args[0]); } However, this solution mixes code handling of both the expected and exceptional cases, making the program harder to understand and write. The alternative code given in Figure 12 reduces this problem: try { System.out.println(args[0]); } catch (ArrayIndexOutOfBoundsException e) { System.out.println("Did not specify the argument to be printed. Terminating program."); System.exit(‐1); } Figure 2: Handling Exceptions It relies on the fact that the Java compiler does insert subscript ‐checking code in the program. It uses three related concepts: exceptions, throw bocks, and catch blocks, which we saw before when looking at user input. When the code detects a subscripting error, it “throws” an exception “out” of the try block, which is then “caught” by the catch block written by the programmer. More precisely, it causes the program to jump out of the try block enclosing the statement that threw the exception, and execute the catch block, passing it an instance of the class ArrayOutOfBoundsException. The catch block declares the class of the exception it expects to handle, and receives as an argument any exception of this class that is thrown in the try block preceding it. It can react appropriately to the exception. In this example it prints for the user an error message indicating the cause of the problem.Exceptions 3 In comparison to the previous solution, this solution has the advantage that the expected and exceptional cases are clearly delineated, making it possible to implement and understand the code in two passes. In the first pass we can worry about the excepted cases and later, in the second pass, we can address the exceptional cases. There are several other advantages of exceptions, which we will see when we study them in more detail. Separating error detection and handling Consider the following code package main; import java.io.BufferedReader; import java.io.InputStreamReader; import java.io.IOException; public class AnArgsPrinter { static BufferedReader inputStream = new BufferedReader(new InputStreamReader(System.in)); public static void main (String args[]) { echoLines(numberOfInputLines(args)); } static int numberOfInputLines(String[] args) { try { return Integer.parseInt(args[0]); } catch (ArrayIndexOutOfBoundsException e) { System.out.println("Did not enter an argument.") return 0; } } static void echoLines (int numberOfInputLines) { try { for (int inputNum = 0; inputNum < numberOfInputLines; inputNum++) System.out.println(inputStream.readLine()); } catch (IOException e) { System.out.println("Did not input " + numberOfInputLines + " input strings before input was closed. "); System.exit(‐1); } }Exceptions 4 }: It is an extension of the previous code that echoes multiple lines. The number of lines to be input is specified as the first argument. As before, if this argument is not specified, a subscript exception is thrown, and the user is given an error message. Recall that a user can close input by entering an EOF (End of File) indicator. If a program tries to read a closed input stream, Java throws an IOException. In this example, such an exception would be thrown if the user closes input before entering the expected lines of input. Therefore the catch block of this exception gives an appropriate error message. Though this example uses exception handlers, it still is not perfectly satisfactory. The function, getNumberOfInputLines() must provide a return value and so it chooses an arbitrary value, which cannot be distinguished from a value actually entered by the user. Moreover, the function is responsible for both computing (the number of lines) and user‐interface issues. Error messages really belong to the user interface as there are multiple ways to report errors. In our example, they could be reported in the system transcript or a dialogue box. Also echoLines() and getNumberOfLines() make different decisions regarding what to do with an error – echoLines() halts the