Standard Input with TextIO

TextIO can redirect input from standard input to a file.

Programming

Why Input Source Matters

A program that asks for data needs to know where that data comes from. In many simple programs, the answer is the person running the program, who types values while the program waits. TextIO is a facility for input and output that can handle this arrangement, but it is not limited to it. The same input operations can be pointed at a file instead, so the program keeps asking for input in the same way while the data arrives from somewhere else.

What do you think happens?

After the statement TextIO.readFile("data.txt") runs, where does the next input requested through TextIO come from?

The person typing at the keyboard
The file named data.txt
Both at the same time

Reveal answer

Answer:

The file named data.txt

Once a file has been selected through TextIO, input requested through TextIO comes from that file rather than from the user's typing. The input operations themselves do not change; only their source does.

The Default Input Source

A common beginner assumption is that TextIO always gets its data from the person running the program. That is only the default arrangement. Standard input is the source that TextIO uses unless something changes it, and in the default arrangement, the data comes from what the user types.

The important idea to hold onto is that the program's input operations can continue to use TextIO while the source of that input changes. The program does not need a different kind of input operation for a file. It only needs to change where TextIO is getting its data.

Tracing the Source Switch

The diagram below shows the data path for a program that uses TextIO. Before any selection is made, the program's requests for input pass through TextIO to standard input, which means the user's typing. After a file has been selected, the same requests pass through TextIO to the file instead. The program's code that asks for input stays the same; the path that the data takes is what has changed.

Where does the program read its data from before and after TextIO is redirected to a file, and what path does the data take?

Worked example

A Program That Switches Sources Once

A program first asks for input through TextIO, then selects the file data.txt, then asks for input through TextIO again. Where does each request get its data?

1
First input request
No file has been selected yet, so TextIO is still using its default source, standard input. The data comes from the person typing.
2
Select the file
The statement TextIO.readFile("data.txt") selects a file with that name as the new source for TextIO.
3
Second input request
Input requested through TextIO now comes from data.txt rather than from the user's typing. The request itself looks the same as the first one.

Result

The first request reads from the user, and the second request reads from data.txt.

Selecting a Source and Restoring Standard Input

TextIO provides several ways to choose its input source. The statement TextIO.readFile("data.txt") selects a file with that name. The statement TextIO.readUserSelectedFile() lets the user choose the file through a GUI-style dialog box. In both cases, once the choice has been made, input requested through TextIO comes from the file rather than from the user's typing.

The source can also be changed back. The statement TextIO.readStandardInput() restores standard input, so later input can again come from the user.

java

TextIO.readFile("data.txt")
// input requests here come from data.txt
TextIO.readStandardInput()
// input requests here come from the user again

TextIO.readFile("data.txt")
// input requests here come from data.txt
TextIO.readStandardInput()
// input requests here come from the user again

Notes on the code

readFile selects a named file as the source
readStandardInput restores the user as the source

Key point

The key sequence is source selection first, input reading second, and restoring standard input afterward if needed. The file does not become a separate kind of TextIO operation. It becomes the source used by TextIO's input functions.

Following Illegal Data Through a Read

Reading from a file changes the way input errors behave. With standard input, a user may be able to correct a mistake while entering data. A file does not give that opportunity during the read. If the program encounters illegal data while trying to read from the file, an error occurs and the program can crash. The flowchart below follows one read through this decision.

What sequence of steps happens when the reader hits a value that doesn't match the expected type, and where does control go next?

The contrast with interactive input is the important part. When a person is typing, a bad value can be noticed and retyped before the program uses it. When the source is a file, the program reads the value directly, and the file offers no chance to fix it in that moment.

Common Mistakes with TextIO File Input

Common mistake
Assuming TextIO always reads from the person at the keyboard
Why it fails
Standard input is only the default source. Once TextIO.readFile or TextIO.readUserSelectedFile has made a selection, input comes from the file.
Do this instead
Track which source is currently selected, and remember that a selection stays in effect until it is changed.
Common mistake
Expecting a bad value in a file to be corrected during the read
Why it fails
A file does not give the user the chance to correct an error while the data is being read, so illegal data can cause an error.
Do this instead
Make sure the data in the file is valid before the program reads it, because the read itself offers no chance to fix it.
Common mistake
Forgetting that the source stays changed after a read
Why it fails
Later input requests still use the file until standard input is restored, so they may read from the file when the programmer expected the user.
Do this instead
Call TextIO.readStandardInput() when later input should come from the user again.

Practical Limits of TextIO

TextIO is an early and relatively simple route into file input and output. Its file I/O capabilities are described as primitive when compared with Java's complete I/O capabilities. That does not make it useless. The source states that TextIO is sufficient for many applications, and it gives learners experience with files before the more complete topic is introduced.

Aspect	Standard input	File selected through TextIO
Where data comes from	The person running the program	A named or user-selected file
Correcting a bad value during the read	The user may be able to correct an error while entering data	No opportunity to correct the error during the read
Illegal data	Handled through the interactive entry	An error occurs and the program can crash
Scope of capability	Default input arrangement	Primitive compared with Java's complete I/O capabilities

Differences between standard input and file input through TextIO, drawn from the source

Practice Predicting the Input Source

EASY

A program runs these steps in order: first it requests input through TextIO, then it runs TextIO.readFile("scores.txt"), then it requests input through TextIO twice, then it runs TextIO.readStandardInput(), and finally it requests input through TextIO once more. For each request, state whether the data comes from the user or from scores.txt.

Hints

The default source is standard input until a selection is made.
A readFile selection stays in effect until readStandardInput is called.
Count the requests between the two source-changing statements.

Your attempt (not saved)

Key Takeaways

TextIO is the input facility whose source can change; by default its data comes from standard input, which is what the user types.
TextIO.readFile("data.txt") selects a named file as the source, and TextIO.readUserSelectedFile() lets the user choose the file through a dialog box.
TextIO.readStandardInput() restores standard input, so later input can again come from the user.
Illegal data in a file can cause an error and crash the program, because a file does not allow the user to correct a value during the read.
TextIO's file I/O is primitive compared with Java's complete I/O, but it is sufficient for many applications and gives learners early experience with files.