COMP 401User Arguments & Exception HandlingSeparating error detection and handlingNested catch blocksChecked vs. Unchecked ExceptionsPrinting exceptions and stack tracesExceptions in FunctionsDefining New Exception ClassesCatching Multiple Exception ClassesTruth in Advertisement of Checked ExceptionsCatching Expected EventsIntra-Method PropagationSummaryExceptions COMP 401Prasun 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 HandlingConsider 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 ArgumentA problem with this program is that the user may have forgotten to supply an argument when executing theprogram. 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. 1Exceptions 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 errorand 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 ExceptionsIt relies on the fact that the Java compiler does insert subscript -checking code in the program. It uses threerelated 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.2Exceptions 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 thefirst 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 handlingConsider the following codepackage 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 stringsbefore input was closed. "); System.exit(-1); }}}:3Exceptions 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, suchan 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