Program Exit Status

A program that keeps information between runs needs a way to store that information outside its own running state. If a phone book forgot every entry as soon as it closed, it would be of little use. The phone book program in this section solves this with a data file.

The idea to hold on to through this article is that the program does not work on the file directly while the user is interacting with it. Instead, the phone book's data is kept in a TreeMap in memory, and the file comes into play at specific moments. Understanding when the file is touched, and what happens if touching it fails, is the goal of this lesson.

When the program starts, the phone book is held in a TreeMap. The user interacts with that in-memory structure rather than with the file. Every modification the user makes, such as adding or changing an entry, is made to the TreeMap while the program is running.

Because the TreeMap is where the work happens, the program can run from start to finish without the file being involved in every action. The file is a place the data goes at the end of the run, not a place that gets updated after every change. Keep this route in mind as you move through the rest of the article: changes go into memory, memory holds them while the program runs, and the file is involved at the end only under certain conditions.

The data file is written at the moment the program ends, but only under one condition: changes were made to the phone book during the run. This means the program has to make a decision at exit. It checks whether the in-memory TreeMap has been modified, and that check determines whether the file write happens at all.

The diagram shows the two paths. If changes were made, the TreeMap is written to the data file before the program finishes. If no changes were made, the write step is skipped and the program finishes without touching the file. A session that only reads entries therefore leaves the saved data exactly as it was.

File operations can fail. The program handles this with a try-catch block that catches IOException. When an IOException occurs while the program reads or writes the phone book data file, the catch block runs instead of the normal path. Control moves away from the regular steps, and the program does not carry on as though the file operation succeeded.

The flowchart shows the two outcomes. The no branch leads to normal continuation. The yes branch runs the catch block, prints the messages, and ends with exit status 1. In the successful case the program keeps going; in the failure case the program stops at the catch block.

A run of the phone book has a clear order: the program starts and holds entries in the TreeMap, the user makes changes, the user quits, and the program writes the file if changes were made. A file error can only occur during the file work, which in this program is the read or write step. The sequence diagram below places that step within the run.

Read the diagram from top to bottom. The file failure appears only near the end, after the user has quit and the program has decided to write. Everything before it, the starting, the in-memory updates, and the quit, has already happened. Everything after it, the remaining logic, does not happen, because the catch block exits the program. So when a run ends with the phone book error message and status 1, you know the failure was in the file operation, not in earlier logic.