How does an application read from and write to text files so that data persists between runs?
Reading from and writing to text and sequential files - opening, reading, writing, appending and closing files, processing records, and handling file errors.
A CCEA A-Level Software Systems Development answer on file handling: opening, reading, writing, appending and closing text and sequential files so data persists between runs, processing records line by line, and handling file errors.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this dot point is asking
CCEA expects you to read from and write to text and sequential files so that data persists between program runs. You must know the file operations - open, read, write, append, close - the difference between opening for reading, writing and appending, how to process records line by line, and how to handle file errors such as a missing file. Pseudocode that reads or writes a file, controlled by an end-of-file test, is examined directly.
The answer
Why files, and the basic operations
You must open a file before using it and close it afterwards. Opening creates a file handle (stream) and a pointer at the correct position; closing flushes any buffered data to disk and releases the handle so other programs can use the file.
Reading, writing and appending
open "log.txt" for appending // keep existing entries
writeLine("User logged in at " + time)
close "log.txt"
Records and file errors
Data is often stored as records, one per line, with fields separated by a delimiter such as a comma (Aoife,13,78). Reading a line and splitting it on the delimiter recovers the fields. Common file errors include the file not existing (file-not-found) when opening to read, the disk being full when writing, and the file being locked by another program. Handle them by checking the file exists before opening, or by using exception handling (a try ... catch) that reports a clear message instead of crashing.
Worked example: load records, add one, save back
Examples in context
Example 1. A high-score table. A game opens scores.txt for reading at start-up to load the leaderboard into an array, and opens it for appending (or rewrites it) when a new score is achieved, so the table survives between sessions. Because the data is in a file, the scores are still there next time the game runs, unlike in-memory variables.
Example 2. An activity log. Each time a user logs in, the application appends a timestamped line to audit.txt. Append mode is essential: write mode would wipe the history every login. A try/catch around the write reports a disk-full or locked-file problem to the administrator rather than crashing the application.
Try this
Q1. State two reasons a file must be closed after it has been written to. [2 marks]
- Cue. Closing flushes buffered data to disk so nothing is lost, and releases the file handle so other programs can use the file.
Q2. A program must add a new line to an existing file without deleting its contents. State the mode it should open the file in. [1 mark]
- Cue. Append mode.
Q3. Name one error that can occur when opening a file to read, and state one way to handle it. [2 marks]
- Cue. File not found; handle it by checking the file exists first, or by catching the exception and showing a clear message.
Exam-style practice questions
Practice questions written in the style of CCEA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
CCEA 20196 marksWrite pseudocode to read every line from a text file `scores.txt` and display each line, and explain why the file must be opened and closed.Show worked answer →
A sequential text file is read one line at a time from the start until the end of the file is reached.
open "scores.txt" for reading
while not endOfFile
line = readLine()
print(line)
end while
close "scores.txt"
The file must be opened before use so the operating system creates a connection (a file handle or stream) and positions a pointer at the start; reading then advances the pointer line by line. The end-of-file test stops the loop when no more data remains. The file must be closed afterwards to release the handle, flush any buffered data to disk and let other programs use the file. Failing to close a file can lose data or lock the file.
Markers reward opening for reading, a loop controlled by the end-of-file test, reading and displaying each line, closing the file, and a correct reason for opening (a connection/pointer) and closing (release the handle and flush data).
CCEA 20215 marksExplain the difference between opening a file for writing and opening it for appending, and describe one error that can occur during file handling and how to deal with it.Show worked answer →
Opening a file for writing creates a new file (or overwrites an existing one), so any previous contents are lost and writing begins at the start. Opening a file for appending opens an existing file and positions the pointer at the end, so new data is added after the existing contents, which are preserved. You append when you want to add records to a log or history without destroying what is already there; you write (overwrite) when you want to replace the contents entirely.
A common file-handling error is trying to open a file for reading that does not exist (or cannot be found at the given path), which raises a file-not-found error. This can be dealt with by checking whether the file exists before opening it, or by using exception handling (a try block) that catches the error and shows the user a clear message rather than letting the program crash. Other errors include the disk being full when writing, or a file being locked by another program.
Markers reward the write-overwrites versus append-preserves distinction with a sensible use for each, a valid file error (such as file not found), and a reasonable way to handle it (check existence or catch the exception).
Related dot points
- Storing application data in arrays, lists and records, and the standard algorithms - linear search, binary search and a simple sort such as bubble sort.
A CCEA A-Level Software Systems Development answer on storing application data in arrays, lists and records, and the standard algorithms: linear search, binary search and a simple sort such as bubble sort, with their requirements and trade-offs.
- The event driven paradigm - events, event handlers, the event loop, event-driven versus procedural programming, and the roles of the operating system and the program.
A CCEA A-Level Software Systems Development answer on the event driven paradigm: what events and event handlers are, how the event loop dispatches them, and how event-driven programming differs from procedural programming.
- Forms and common GUI controls, their properties, events and methods, wiring controls to handlers, and the human-computer interaction principles of good interface design.
A CCEA A-Level Software Systems Development answer on forms and GUI controls: common controls and their properties, events and methods, wiring controls to handlers, and the human-computer interaction principles behind good interface design.
- Testing strategies for applications, debugging tools (breakpoints, stepping, watches), exception handling with try and catch, and producing robust software.
A CCEA A-Level Software Systems Development answer on testing and debugging event driven applications: test strategies, debugging tools such as breakpoints, stepping and watches, and exception handling with try and catch for robust software.
Sources & how we know this
- CCEA GCE Software Systems Development specification — CCEA (2016)