Exceptions and try..catch in Java

Imagine a small program that reads numbers from a file whose name the user types in. It then reports how many numbers it read, their sum, and their average. This is the program used in this exercise, named AverageNumbersFromFile. It sounds simple, but the file can be bad in two different ways. The file name may not point to a readable file, and the file may contain something other than numbers of type double. A program that does not plan for either situation would stop at the first problem. The program is designed to survive both, and the tool that makes this possible is the try..catch block.

Without any handling, one of these problems would stop the program. Exception handling gives the program a way to respond to such a problem and then keep going. The phrase exception handling describes the whole approach, and try..catch is the Java syntax that carries it out.

A try..catch handler has two parts. The try part holds the statements that might fail. The catch part names the kind of exception it handles and holds the code that runs when that exception occurs. The schematic below uses the general form only. The exercise's own calls are described in the sections that follow.

The exercise uses this same pattern twice. The call to TextIO.readFile is in the try part of the first handler, and IllegalArgumentException is caught in its catch part. The second handler wraps the loop that calls TextIO.getDouble() repeatedly. Both handlers catch IllegalArgumentException, but the code in each catch clause is different because the two blocks serve different purposes.

The second try..catch wraps the reading loop. On each pass, the loop calls TextIO.getDouble(). Each successful call is followed by a count increment and an addition to the sum. The clearest way to understand the loop is to watch count and sum change from pass to pass. The example below uses a generated file that holds 3.5, 4.0, a token that cannot be read as a double, and then 10.0.

The flowchart below shows the path that execution takes on each pass through the try block. At the decision point, the program asks whether the value was read successfully. If the answer is no, the value is stored, the count goes up, and the value is added to the sum, and then the loop repeats. If the answer is yes, the rest of the try block is skipped. The count and sum keep the values they had at that moment, and control moves directly to the catch clause.

The loop reads until the data runs out, and running out of data causes an exception too. The source explains that this end-of-file IllegalArgumentException is expected and is not treated as an error, so its catch clause is intentionally empty. The loop stops, and the program reports its results normally. A genuine runtime error, such as an unreadable file name, is handled differently because the catch clause has real work to do.