Unit 11: Files and Persistence

Unit 10 built the exception machinery and deliberately left file input and output on the table, because a missing file is the first place a checked exception stops being a rule to memorise and starts being obviously right. This unit spends that credit. It covers where a program's data goes when it closes, reading a text file with Scanner, turning lines into objects, writing with PrintWriter, closing the file and the block that closes it for you, what to do when the file is not there, choosing a record format you can read back, and loading on start and saving on change. String.split is new material here and is taught from zero at Lesson 3 rather than assumed.

The performance task is The Thing That Remembers. The application loads what it saved last time, lets the user change the data during the session, and writes it back in a format it can read again. It must handle a missing file without crashing, handle at least two kinds of bad line, and close every file it opens. Each product choice reuses a class the student already wrote in Unit 5, 6, 8 or 9, so build days go to persistence rather than to inventing a domain.

Evidence is the source, the record format specification written before the code, a sample data file, and a persistence test log of four runs recorded in order: first launch with no data file, add and exit, relaunch and prove the data came back, and relaunch with a data file a partner deliberately corrupted. The fourth run is the heaviest criterion, because a program that reloads its own clean data is not persistent, it is lucky. A teacher gets a plan and a substitute plan for each of the twelve lessons, answer keys, and tiered handouts.

The unit runs 12 instructional days.