Why is "Forgetting CLOSEFILE, or closing only one of several open files." a common mistake in File Processing and Exception Handling?

Why it happens: Students focus on the reading/writing and treat closing as optional, or open two files but write only one CLOSEFILE. How to avoid it: Every OPENFILE needs its own matching CLOSEFILE. Closing is where written data is saved and the file is released. Source: Examiner reports regularly note marks lost for missing CLOSEFILE statements.

Why is "Using FOR WRITE when the task says to add to a file, wiping the existing data." a common mistake in File Processing and Exception Handling?

Why it happens: Students see 'write to the file' and pick WRITE without noticing the data must be kept. How to avoid it: If the question says 'add', 'keep existing records' or 'do not delete', use FOR APPEND. FOR WRITE empties the file first.

Why is "Testing EOF after READFILE instead of before it, so the loop reads one line past the end." a common mistake in File Processing and Exception Handling?

Why it happens: Students put the EOF check at the bottom of the loop (post-test) rather than as the WHILE condition. How to avoid it: Always loop WHILE NOT EOF("name") DO and READFILE inside it, so EOF is checked before each read.

Why is "Doing arithmetic or numeric comparison on a value read straight from a text file without converting it." a common mistake in File Processing and Exception Handling?

Why it happens: Lines from a text file are STRINGs, but they look like numbers, so students forget the conversion. How to avoid it: Convert with STRING_TO_NUM before any calculation, and NUM_TO_STRING before writing a number to a text file.

Why is "On a random file, calling PUTRECORD straight after GETRECORD without SEEKing back, so the record is written to the wrong position." a common mistake in File Processing and Exception Handling?

Why it happens: Students do not realise GETRECORD advances the file position past the record just read. How to avoid it: SEEK to the record number again immediately before PUTRECORD to overwrite the correct record.

Why is "Treating exception handling as a replacement for ordinary input validation (or vice versa, ignoring exceptions entirely)." a common mistake in File Processing and Exception Handling?

Why it happens: Students learn TRY…EXCEPT and apply it everywhere, or rely only on IF checks and let conversions crash the program. How to avoid it: Use validation for predictable conditions (e.g. a value in range) and exception handling for unpredictable run-time failures (e.g. bad type conversion, missing file).

Cambridge International A Levels Computer Science (9618)

File Processing and Exception Handling

0% Complete

Detailed Study Notes

Detailed notes on Further Programming for Cambridge International A Levels Computer Science, covering key concepts, explanations, examples, and exam-focused revision points.

File Processing and Exception Handling — Cambridge AS & A Level Computer Science 9618 Study Notes (2027-2029)

How to open, read, write and close files in Cambridge pseudocode; how to read and write whole RECORDs; how serial, sequential and random files differ (with SEEK / GETRECORD / PUTRECORD for direct access); and how to write robust code with TRY…EXCEPT exception handling. This is A-Level content examined in Paper 3 (written) and Paper 4 (practical) — answers are in pseudocode and no calculator is used.

At a glance

A file gives persistent storage on secondary storage — data survives after the program ends.
Every file follows open → process → close: OPENFILE, READFILE/WRITEFILE, CLOSEFILE.
Three open modes: FOR READ (read), FOR WRITE (fresh/overwrite), FOR APPEND (add to end).
A record is a composite type with named fields, accessed with dot notation and stored field by field.
Serial = arrival order; sequential = ordered by key; random = direct access by record number.
Random files use SEEK (move to a position), GETRECORD (read it), PUTRECORD (write it back).
An exception is a run-time error (file not found, divide by zero, bad conversion) that would crash the program.
Exception handling (TRY … EXCEPT … ENDTRY) catches it so the program responds gracefully.
Use exception handling for unpredictable run-time failures; use ordinary validation for predictable conditions.

What you’ll learn

Mapped to the Cambridge International A Level 9618 syllabus (2027-2029).

20.2 — Write code to open a file in READ, WRITE or APPEND mode and to close a file after use.
20.2 — Write code to read a record from, and write a record to, a file.
20.2 — Perform file-processing operations on serial, sequential and random files.
20.2 — Show understanding of what an exception is and the importance of exception handling.
20.2 — Know when it is appropriate to use exception handling.
20.2 — Write code that uses exception handling (TRY … EXCEPT).

File modes and the open → process → close pattern

Open a file in a mode, read or write it, then always close it.

Data in variables lives in RAM and is lost when the program ends. A file stores data on secondary storage, so it is persistent — it survives the run and can be read back later.

All file handling in 9618 follows the same three-stage lifecycle:

Open the file with a mode — what you intend to do.
Process the file — read records/lines from it, or write them to it.
Close the file when finished, so the data is saved and the file is released.

The three modes are:

Mode	What it does	Use it to…
FOR READ	opens an existing file to read from the start	read data back
FOR WRITE	creates a new, empty file (overwrites any existing one)	start a fresh file
FOR APPEND	opens an existing file and writes at the end	add to existing data

The Cambridge pseudocode commands are:

OPENFILE "Data.txt" FOR READ        // or FOR WRITE / FOR APPEND
READFILE "Data.txt", Variable       // read the next line into Variable
WRITEFILE "Data.txt", Value         // write one line
CLOSEFILE "Data.txt"                // close it (saves + releases)

The EOF function tells you when reading has reached the end:

EOF("filename") returns TRUE at the end of the file, FALSE while lines remain.

So the standard read loop runs WHILE NOT EOF — checking EOF before each read:

DECLARE Line : STRING
OPENFILE "Data.txt" FOR READ
WHILE NOT EOF("Data.txt") DO
   READFILE "Data.txt", Line
   OUTPUT Line
ENDWHILE
CLOSEFILE "Data.txt"

Files give persistent storage; variables (RAM) are temporary.
Lifecycle: OPENFILE → READFILE/WRITEFILE → CLOSEFILE.
FOR READ reads; FOR WRITE makes a fresh file; FOR APPEND adds to the end.
Loop WHILE NOT EOF("name") and CLOSEFILE every file you open.

See the full worked example for file processing and exception handling →

Reading and writing RECORDs

A record bundles named fields; write each field, read them back in order.

A record is a composite data type — a single value made of several named fields, possibly of different types. You define one with TYPE … ENDTYPE:

TYPE Student
   StudentID : INTEGER
   Name      : STRING
   Mark      : INTEGER
ENDTYPE

You declare a variable of that type and access each field with dot notation (RecordVar.FieldName):

DECLARE NewStudent : Student
NewStudent.StudentID ← 1024
NewStudent.Name ← "Aisha"
NewStudent.Mark ← 81

Writing a record to a text file. Write each field on its own line, so the structure is fixed and can be read back. Numbers must be turned into strings first with NUM_TO_STRING:

OPENFILE "Students.txt" FOR APPEND
WRITEFILE "Students.txt", NUM_TO_STRING(NewStudent.StudentID)
WRITEFILE "Students.txt", NewStudent.Name
WRITEFILE "Students.txt", NUM_TO_STRING(NewStudent.Mark)
CLOSEFILE "Students.txt"

Reading a record back. Read the lines in the same order they were written, converting numeric fields with STRING_TO_NUM:

DECLARE Current : Student
DECLARE Temp : STRING
READFILE "Students.txt", Temp
Current.StudentID ← STRING_TO_NUM(Temp)
READFILE "Students.txt", Current.Name
READFILE "Students.txt", Temp
Current.Mark ← STRING_TO_NUM(Temp)

The golden rule: write the fields in a fixed order and read them back in exactly that order, converting numbers each way.

A record is a composite type with named fields, defined by TYPE … ENDTYPE.
Access fields with dot notation: Record.Field.
Write each field on its own line; convert numbers with NUM_TO_STRING.
Read fields back in the same order; convert with STRING_TO_NUM.

See the full worked example for file processing and exception handling →

Serial, sequential and random file processing

Arrival order vs ordered-by-key vs direct access by record number.

Files differ in how records are organised and how you access them.

File type	Organisation	Access
Serial	records in arrival order (no ordering)	read from the start, one by one
Sequential	records ordered by a key field	still read in order, but easier to merge/search
Random	each record has a position / record number (often from a hashing algorithm)	direct access — jump straight to a record

A serial or sequential file is processed with the normal read loop — you must pass through earlier records to reach a later one. A random (direct-access) file can jump straight to any record using SEEK, then read or write it with GETRECORD / PUTRECORD:

SEEK "Stock.dat", 7            // move to record position 7
GETRECORD "Stock.dat", Item    // read that record into Item
Item.Quantity ← Item.Quantity + 10
SEEK "Stock.dat", 7            // re-seek: GETRECORD moved the position on
PUTRECORD "Stock.dat", Item    // write the record back to position 7

Random: SEEK straight to 7 5 6 … 7 SEEK jumps directly — near-constant access time

Direct access is why a random file is the right choice when single records must be looked up or updated quickly and individually — for example a bank balance or a stock level during a live transaction. (Hashing of keys to positions links to Topic 13.2.)

Serial = arrival order; sequential = ordered by key; random = positioned records.
Serial/sequential are read in order; random gives direct access.
Random files: SEEK to a position, GETRECORD to read, PUTRECORD to write.
Re-SEEK before PUTRECORD because GETRECORD advances the position.

See the full worked example for file processing and exception handling →

What an exception is and why we handle it

An exception is a run-time error; handling it stops the program crashing.

An exception is a run-time error — an abnormal event that happens while the program is running and that would otherwise make it stop/crash. Typical causes:

trying to open a file that does not exist;
dividing by zero;
converting non-numeric input (e.g. "hello") into a number.

These cannot all be ruled out in advance — the user or the data can do something unexpected. Exception handling lets the program detect the error and respond gracefully (show a message, skip the bad item, try again) instead of terminating.

When is it appropriate? Use exception handling around operations that can fail at run time in hard-to-predict ways — chiefly file access and converting user/file input to numbers. It is not a replacement for ordinary validation of predictable conditions (e.g. checking a number is within a known range, or a string is not empty) — those should still use normal IF checks. A good design uses both: validation for the expected, exception handling for the unexpected.

An exception is a run-time/abnormal error that would crash the program.
Examples: file not found, division by zero, invalid type conversion.
Exception handling lets the program respond gracefully instead of stopping.
Use it for unpredictable run-time failures, not for predictable validation.

See the full worked example for file processing and exception handling →

Writing exception handling (TRY … EXCEPT)

Put risky code in TRY; recovery code in EXCEPT; the program continues.

Cambridge pseudocode uses this structure:

TRY
   ... code that might fail ...
EXCEPT
   ... handle the error ...
ENDTRY

The TRY block holds the code that might raise an exception. If none is raised, the EXCEPT block is skipped. If one is raised, execution jumps immediately to the EXCEPT block, which handles it; the program then carries on after ENDTRY.

Catching a bad conversion / division by zero:

INPUT UserInput
TRY
   Age ← STRING_TO_NUM(UserInput)
   Result ← 1000 DIV Age
   OUTPUT "Result = ", Result
EXCEPT
   OUTPUT "Invalid input — enter a non-zero number."
ENDTRY

Catching a missing file (so the program does not crash if it is not there):

TRY
   OPENFILE "Config.txt" FOR READ
   READFILE "Config.txt", Setting
   CLOSEFILE "Config.txt"
EXCEPT
   OUTPUT "Config file missing — using default settings."
ENDTRY

Keeping going through bad data — wrap the risky part inside the read loop so one bad line does not stop the whole file:

WHILE NOT EOF("Prices.txt") DO
   READFILE "Prices.txt", Line
   TRY
      Price ← STRING_TO_NUM(Line)
      OUTPUT Price * 1.2
   EXCEPT
      OUTPUT "Skipping invalid line: ", Line
   ENDTRY
ENDWHILE

Some languages also offer a FINALLY block that runs whether or not an exception occurred — useful for clean-up such as closing a file. Keep TRY blocks small: protect only the line(s) that can fail, so the handler stays meaningful.

TRY holds risky code; EXCEPT runs only if an exception is raised; ENDTRY ends it.
If no exception occurs, EXCEPT is skipped and the program continues.
Put TRY…EXCEPT inside the loop to skip a single bad line and keep going.
An optional FINALLY block runs afterwards either way (e.g. to close a file).

See the full worked example for file processing and exception handling →

Quick recap

Files give persistent storage; every file follows open → process → close.
OPENFILE sets the mode: READ (read), WRITE (fresh/overwrite), APPEND (add to end).
A record is a composite type with named fields — write each field, read them back in order.
Serial = arrival order; sequential = ordered by key; random = direct access by record number.
Random files use SEEK, GETRECORD and PUTRECORD; re-SEEK before PUTRECORD.
An exception is a run-time error that would crash the program; handling it lets it recover.
TRY holds risky code, EXCEPT handles the error; use it for unpredictable failures, not validation.

Memorise this

Verbatim phrases and definitions Cambridge mark schemes credit.

OPENFILE "name" FOR READ / WRITE / APPEND
READFILE "name", Variable / WRITEFILE "name", Value
EOF("name") returns TRUE at the end of the file
CLOSEFILE "name" — close every file you open
Random files: SEEK "name", n ; GETRECORD "name", Rec ; PUTRECORD "name", Rec
Re-SEEK before PUTRECORD (GETRECORD advances the position).
TRY … EXCEPT … ENDTRY — exception = run-time error; handling avoids a crash.
Serial = arrival order; sequential = ordered by key; random = direct access.

How it’s examined

Section 20.2 is A-Level content assessed in Paper 3 (Advanced Theory, 1 hour 30 minutes, 75 marks, written) AND Paper 4 (Practical, 2 hours 30 minutes, 75 marks) — answers are written in pseudocode (or the chosen programming language in Paper 4) and no calculator is needed. Expect: a 'what is an exception / when is it appropriate' theory question (contrast with validation for the top marks); pseudocode to open, read/write a record, and close a file; serial vs sequential vs random comparison with a SEEK/GETRECORD/PUTRECORD update on a random file; and code that wraps risky operations in TRY…EXCEPT. Always include the correct mode, an EOF-controlled read loop, a CLOSEFILE for every file, and a re-SEEK before PUTRECORD.

Sources: Cambridge International AS & A Level Computer Science 9618 syllabus (2027-2029), section 20.2. Last reviewed 2026-06-21.

Take this whole topic with you

Step-by-step worked examples — File Processing and Exception Handling

Step-by-step solutions to past-paper-style questions on file processing and exception handling, written exactly the way a tutor would explain them at the board.

Question type:

1Open, read and close a text file
Getting startedMulti-step problem• 9618 Paper 3 style• file, OPENFILE, READFILE, EOF, AO2
Question
Write pseudocode to open the text file Names.txt for reading, output every line in the file, then close the file. (4 marks)
Step-by-step solution
1. Step 1
  Declare a variable to hold each line, then OPEN the file in READ mode. Reading always starts at the first line.
  $DECLARE Line : STRING$
2. Step 2
  Loop WHILE NOT EOF so the loop stops at the end of the file. EOF must be tested BEFORE each read so you never read past the last line.
3. Step 3
  Inside the loop, READFILE pulls the next line into the variable, then OUTPUT it.
4. Step 4
  After the loop, CLOSEFILE releases the file. Every OPENFILE needs a matching CLOSEFILE.
Answer
DECLARE Line : STRING OPENFILE "Names.txt" FOR READ WHILE NOT EOF("Names.txt") DO READFILE "Names.txt", Line OUTPUT Line ENDWHILE CLOSEFILE "Names.txt"
Examiner tip
Marks: OPENFILE … FOR READ (1), WHILE NOT EOF loop (1), READFILE inside the loop (1), CLOSEFILE (1). The single most common slip is forgetting CLOSEFILE or testing EOF after the read instead of before it.
2Write to a new file and append to it
Getting startedMulti-step problem• 9618 Paper 3 style• file, WRITEFILE, WRITE, APPEND, AO2
Question
(a) Write pseudocode to create a new text file Log.txt and write two lines to it. (b) Write pseudocode to add a third line to the SAME file without deleting the existing lines. (4 marks)
Step-by-step solution
1. Step 1
  (a) FOR WRITE creates a new, empty file (overwriting any existing one). WRITEFILE writes one line each time it is called.
2. Step 2
  Close the file so the two lines are saved.
3. Step 3
  (b) To keep the existing data, reopen the file FOR APPEND — this writes after the current contents. Opening FOR WRITE again would erase the first two lines.
4. Step 4
  WRITEFILE the new line, then CLOSEFILE.
Answer
(a)

OPENFILE "Log.txt" FOR WRITE WRITEFILE "Log.txt", "Line one" WRITEFILE "Log.txt", "Line two" CLOSEFILE "Log.txt"

(b)

OPENFILE "Log.txt" FOR APPEND WRITEFILE "Log.txt", "Line three" CLOSEFILE "Log.txt"
Examiner tip
The discriminator is mode choice: 'add without deleting' = FOR APPEND, never FOR WRITE. WRITE empties the file first, which would lose the existing two lines — a heavily penalised error.
3Write a RECORD to a file
Building confidenceMulti-step problem• 9618 Paper 3 style• record, TYPE, WRITEFILE, AO2
Question
A student record stores an ID, a name and a mark. Define a suitable record type, then write pseudocode that takes one student's details as input and writes them to the file Students.txt. (5 marks)
Step-by-step solution
1. Step 1
  Define the composite data type with TYPE … ENDTYPE. Each field has a name and a data type.
  $TYPE Student\\n StudentID : INTEGER\\n Name : STRING\\n Mark : INTEGER\\nENDTYPE$
2. Step 2
  Declare a variable of that record type, then input each field using dot notation (RecordVar.FieldName).
3. Step 3
  Open the file FOR WRITE (or APPEND to add to existing students), then WRITEFILE each field on its own line so the record can be read back field by field later.
4. Step 4
  Close the file. Writing each field on a separate line means a later read loop can pull them back in the same order.
Answer
TYPE Student StudentID : INTEGER Name : STRING Mark : INTEGER ENDTYPE DECLARE NewStudent : Student INPUT NewStudent.StudentID INPUT NewStudent.Name INPUT NewStudent.Mark OPENFILE "Students.txt" FOR APPEND WRITEFILE "Students.txt", NUM_TO_STRING(NewStudent.StudentID) WRITEFILE "Students.txt", NewStudent.Name WRITEFILE "Students.txt", NUM_TO_STRING(NewStudent.Mark) CLOSEFILE "Students.txt"
Examiner tip
A record is a single value with several named fields, accessed with dot notation. Writing the fields one per line gives a fixed structure to read back. APPEND is used so existing students are not overwritten; FOR WRITE would also be accepted if the question said to create a fresh file.
4Read RECORDs back from a file
Building confidenceMulti-step problem• 9618 Paper 3 style• record, READFILE, EOF, STRING_TO_NUM, AO2
Question
Using the file Students.txt from the previous question (three lines per student: ID, name, mark), write pseudocode to read every student back into a record and output the name of each student who scored 50 or more. (6 marks)
Step-by-step solution
1. Step 1
  Open the file FOR READ and loop WHILE NOT EOF, reading the three lines of one record per pass.
2. Step 2
  Lines from a text file are STRINGs, so convert the numeric fields back with STRING_TO_NUM before comparing.
3. Step 3
  Read the three lines into the three fields of the record in the SAME order they were written.
4. Step 4
  Test the mark; if it is 50 or more, output the name. Close the file after the loop.
Answer
DECLARE Current : Student DECLARE Temp : STRING OPENFILE "Students.txt" FOR READ WHILE NOT EOF("Students.txt") DO READFILE "Students.txt", Temp Current.StudentID ← STRING_TO_NUM(Temp) READFILE "Students.txt", Current.Name READFILE "Students.txt", Temp Current.Mark ← STRING_TO_NUM(Temp) IF Current.Mark >= 50 THEN OUTPUT Current.Name ENDIF ENDWHILE CLOSEFILE "Students.txt"
Examiner tip
Read the fields back in the exact order they were written, and convert numeric strings with STRING_TO_NUM before any arithmetic or numeric comparison. Comparing the STRING "49" with the number 50 is a classic error.
5Direct access to a random file (SEEK / GETRECORD / PUTRECORD)
StretchMulti-step problem• 9618 Paper 3 style• random file, SEEK, GETRECORD, PUTRECORD, AO2
Question
A random-access file Stock.dat stores StockItem records, one per fixed-length position. Write pseudocode to (a) read the record at position 7 into a variable, increase its quantity by 10, and write it back, and (b) explain why a random file can do this faster than a serial file. (6 marks)
Step-by-step solution
1. Step 1
  Open the random file. SEEK moves directly to the chosen record position — no need to read every record before it.
2. Step 2
  GETRECORD copies the record at the current position into a record variable.
  $GETRECORD "Stock.dat", ThisItem$
3. Step 3
  Update the field with dot notation, then SEEK back to the same position before writing (GETRECORD moved the position on).
4. Step 4
  PUTRECORD writes the record back into that exact position, overwriting the old one. Then close the file.
5. Step 5
  (b) A random file allows DIRECT access: SEEK jumps straight to record 7 using its position, so access time is roughly constant. A serial file must be read sequentially from the start until the wanted record is reached, so it is slower on average.
Answer
(a)

DECLARE ThisItem : StockItem OPENFILE "Stock.dat" FOR RANDOM SEEK "Stock.dat", 7 GETRECORD "Stock.dat", ThisItem ThisItem.Quantity ← ThisItem.Quantity + 10 SEEK "Stock.dat", 7 PUTRECORD "Stock.dat", ThisItem CLOSEFILE "Stock.dat"

(b) A random file supports direct access — SEEK jumps straight to record 7 by its position, giving near-constant access time. A serial file has no record numbers, so it must be read in order from the beginning until the required record is found, which is slower.
Examiner tip
Key A-Level points: SEEK sets the position, GETRECORD reads the whole record there, PUTRECORD writes it back. SEEK again before PUTRECORD because GETRECORD advances the file position. Direct access vs sequential search is the standard 'why is it faster' answer.
6Exception handling for input and file access
StretchMulti-step problem• 9618 Paper 3 style• exception, TRY, EXCEPT, robustness, AO2
Question
A program asks the user for their age and divides a target by it. Using TRY…EXCEPT, write pseudocode that (a) safely converts the input to a number and (b) handles the case where the user enters 0 (which would cause a division by zero). Explain why exception handling, not validation, is appropriate for the conversion. (6 marks)
Step-by-step solution
1. Step 1
  Place the operations that might fail at run time — the string-to-number conversion and the division — inside a TRY block.
2. Step 2
  If STRING_TO_NUM is given non-numeric text, or the division divides by zero, an exception is raised and control jumps to the EXCEPT block.
3. Step 3
  The EXCEPT block reports the problem and lets the program continue gracefully instead of crashing.
4. Step 4
  (Reason) The conversion can fail for many unpredictable run-time reasons (the user could type anything). A TRY…EXCEPT catches any such run-time error in one place; ordinary validation is better suited to predictable conditions like a known number range.
Answer
DECLARE UserInput : STRING DECLARE Age, Result : INTEGER OUTPUT "Enter your age:" INPUT UserInput TRY Age ← STRING_TO_NUM(UserInput) Result ← 1000 DIV Age OUTPUT "Result = ", Result EXCEPT OUTPUT "Invalid input — please enter a non-zero number." ENDTRY

Exception handling is appropriate here because the conversion and division can fail at run time in ways that would otherwise crash the program; a TRY…EXCEPT catches the error and lets the program respond gracefully. It is not a replacement for validating a predictable condition such as a fixed age range.
Examiner tip
An exception is a run-time error (e.g. invalid type conversion, division by zero, file not found). TRY holds the risky code; EXCEPT runs only if an exception is raised. Examiners want the point that exception handling stops the program crashing and is for unpredictable run-time failures, not a substitute for normal input validation.

Model Answers — File Processing and Exception Handling

High-scoring sample answers for file processing and exception handling on the Cambridge IGCSE paper, with examiner-style notes mapping each response to the mark scheme and assessment objectives.

Question 1
9618 Paper 3 style3 marks
State the three modes a file can be opened in, and describe what each one is used for. (3 marks)
Model answer
READ — opens an existing file so its contents can be read, starting at the beginning.

WRITE — creates a new, empty file (overwriting any existing file of the same name); used to write data into a fresh file.

APPEND — opens an existing file and adds new data at the end without deleting the current contents; used to add to data already stored.
Why this scores
1 mark per mode correctly described. The discriminator is APPEND vs WRITE: APPEND keeps existing data and adds to the end, whereas WRITE empties/overwrites the file first.
Question 2
9618 Paper 3 style4 marks
Explain what is meant by an exception, and describe when it is appropriate to use exception handling. (4 marks)
Model answer
What an exception is: An exception is a run-time error — an abnormal event that occurs while the program is running and that would otherwise cause it to stop/crash. Examples include trying to open a file that does not exist, dividing by zero, or converting non-numeric input into a number.

What exception handling does: Exception handling lets the program detect such an error and respond to it gracefully (for example by displaying a message and continuing) instead of terminating unexpectedly.

When it is appropriate: It is appropriate around operations that can fail at run time in ways that are hard to predict — for example file access (the file may be missing or locked) and converting user input to a number. It is not a substitute for ordinary validation of predictable conditions (such as checking a number is within a known range), which should still be done with normal checks.
Why this scores
Marks for: run-time/abnormal error (1); a valid example such as file not found or division by zero (1); program responds gracefully rather than crashing (1); appropriate for unpredictable run-time failures, not a replacement for validation (1). The contrast with validation is the high-value A-Level point.
Question 3
9618 Paper 3 style5 marks
A record type Member has fields MemberID (INTEGER), FullName (STRING) and Active (BOOLEAN). Write pseudocode that inputs one member's details and appends the record to the text file Members.txt, writing each field on its own line. (5 marks)
Model answer
DECLARE NewMember : Member INPUT NewMember.MemberID INPUT NewMember.FullName INPUT NewMember.Active OPENFILE "Members.txt" FOR APPEND WRITEFILE "Members.txt", NUM_TO_STRING(NewMember.MemberID) WRITEFILE "Members.txt", NewMember.FullName WRITEFILE "Members.txt", NewMember.Active CLOSEFILE "Members.txt"

Each field is read into the record using dot notation, the file is opened FOR APPEND so existing members are not lost, each field is written on its own line so it can be read back in order, and the file is closed to save the data.
Why this scores
Marks: open FOR APPEND (1, accept FOR WRITE if creating a fresh file), input/assign fields with dot notation (1), three WRITEFILE statements for the three fields (1), correct order matching the fields (1), CLOSEFILE (1). Numeric fields should be converted with NUM_TO_STRING before writing to a text file.
Question 4
9618 Paper 3 style6 marks
A company stores customer records. Compare how records are organised and accessed in a serial file, a sequential file and a random file, and give one situation where a random file is the best choice. (6 marks)
Model answer
Serial file: Records are stored one after another in the order they were added (chronological / arrival order), with no ordering by key. To find a record you must read from the start, record by record, until you reach it (sequential/serial access).

Sequential file: Records are stored in order of a key field (for example ascending customer ID). They are still accessed in order from the start, but the ordering makes it easier to merge files and to stop searching early once the key would have been passed.

Random (direct-access) file: Each record has a position (record number), often calculated from the key by a hashing algorithm. SEEK moves straight to that position so a record can be read or written directly, without reading the records before it — giving near-constant access time.

Best choice for a random file: When records must be accessed quickly and individually in no particular order — for example looking up or updating a single customer's balance instantly during an online transaction, where reading the whole file each time would be far too slow.
Why this scores
2 marks per file type (organisation + access), capped, plus the applied example. Strong answers name 'order of arrival' (serial), 'ordered by key' (sequential) and 'direct access via record number/hash' (random). Linking the random-file example to fast individual lookups secures the application mark.
Question 5
9618 Paper 3 style6 marks
A program reads a price from a file and converts it to a number for a calculation. (a) Write pseudocode that uses exception handling so the program does not crash if a line is not a valid number. (b) Explain why exception handling is more suitable here than checking the value with an IF statement before converting. (6 marks)
Model answer
(a)

DECLARE Line : STRING DECLARE Price : REAL OPENFILE "Prices.txt" FOR READ WHILE NOT EOF("Prices.txt") DO READFILE "Prices.txt", Line TRY Price ← STRING_TO_NUM(Line) OUTPUT "Price with tax: ", Price * 1.2 EXCEPT OUTPUT "Skipping invalid line: ", Line ENDTRY ENDWHILE CLOSEFILE "Prices.txt"

(b) The data in the file comes from outside the program and could be malformed in many unpredictable ways (blank lines, letters, stray symbols). Writing IF checks to anticipate every possible invalid format is difficult and error-prone. The conversion itself raises an exception whenever it cannot produce a number, so wrapping it in TRY…EXCEPT catches any such run-time failure in one place and lets the program continue with the remaining lines instead of crashing. Exception handling therefore handles unpredictable run-time errors cleanly, whereas an IF is better for a single, predictable, well-defined condition.
Why this scores
(a) up to 3: TRY around the conversion/calculation (1), EXCEPT with a sensible recovery (1), still reads the whole file with the loop and closes it (1). (b) up to 3: file data is unpredictable/external (1), one handler catches any conversion failure rather than enumerating every bad case (1), program continues gracefully instead of crashing (1).
Question 6
9618 Paper 3 style6 marks
A bank stores account records in a random-access file Accounts.dat, where the record number equals the account number. Write pseudocode to add 50 to the balance of account number 42, and explain the purpose of each file command you use. (6 marks)
Model answer
DECLARE TheAccount : Account OPENFILE "Accounts.dat" FOR RANDOM SEEK "Accounts.dat", 42 GETRECORD "Accounts.dat", TheAccount TheAccount.Balance ← TheAccount.Balance + 50 SEEK "Accounts.dat", 42 PUTRECORD "Accounts.dat", TheAccount CLOSEFILE "Accounts.dat"

Purpose of each command:

OPENFILE … FOR RANDOM opens the file for direct (random) access.

SEEK "Accounts.dat", 42 moves the file position directly to record 42 (the account's position) without reading earlier records.

GETRECORD reads the whole record at that position into the variable TheAccount.

The balance field is updated using dot notation.

SEEK 42 again repositions to record 42, because GETRECORD advanced the position past it.

PUTRECORD writes the updated record back into position 42, overwriting the old one.

CLOSEFILE saves and releases the file.
Why this scores
Marks: OPEN FOR RANDOM (1), SEEK to the record number (1), GETRECORD into a variable (1), update the field (1), SEEK again + PUTRECORD back to the same position (1), CLOSEFILE (1). The re-SEEK before PUTRECORD is the A* detail many candidates omit, which would overwrite the wrong record.

Key Definitions and Keywords — File Processing and Exception Handling

Definitions to memorise and the exact keywords mark schemes credit for file processing and exception handling answers — sharpened from recent examiner reports for the 2026 Cambridge IGCSE sitting.

File
Examiner keyword
A collection of related data stored on secondary storage (e.g. a disk or SSD) so that it persists beyond the run of a program and can be read back later by the same or a different program.
Record
Examiner keyword
A composite data type made up of several named fields, possibly of different data types, that together describe one item (e.g. a Student record holding an ID, a name and a mark). Fields are accessed with dot notation.
Example
Student.Mark accesses the Mark field of a Student record.
Serial file
Examiner keyword
A file in which records are stored one after another in the order they were added (arrival/chronological order), with no ordering by key. Records are found by reading from the start.
Sequential file
Examiner keyword
A file in which records are stored in order of a key field (e.g. ascending ID). Like a serial file it is accessed in order, but the ordering makes merging and searching more efficient.
Random (direct-access) file
Examiner keyword
A file in which each record has a position (record number), often derived from the key by a hashing algorithm, so any record can be read or written directly using SEEK without reading the records before it.
READ mode
Examiner keyword
A file open mode (OPENFILE … FOR READ) that opens an existing file so its contents can be read, starting at the beginning.
WRITE mode
Examiner keyword
A file open mode (OPENFILE … FOR WRITE) that creates a new, empty file, overwriting any existing file of the same name, ready for data to be written into it.
APPEND mode
Examiner keyword
A file open mode (OPENFILE … FOR APPEND) that opens an existing file and writes new data at the end, keeping the existing contents.
EOF (end of file)
Examiner keyword
A function, EOF("filename"), that returns TRUE when the end of the file has been reached and FALSE while lines remain. Used to control a read loop (WHILE NOT EOF).
Exception
Examiner keyword
A run-time error or abnormal event that occurs while a program is running (e.g. file not found, division by zero, invalid type conversion) and that would otherwise cause the program to crash.
Exception handling
Examiner keyword
A programming technique that detects an exception when it occurs and responds to it gracefully (e.g. shows a message and continues) instead of letting the program terminate. In Cambridge pseudocode it uses TRY … EXCEPT … ENDTRY.
TRY / EXCEPT (and FINALLY)
Examiner keyword
TRY holds the code that might raise an exception; EXCEPT holds the code that runs only if an exception is raised; an optional FINALLY block holds code that runs afterwards whether or not an exception occurred (e.g. closing a file).

Common Mistakes and Misconceptions — File Processing and Exception Handling

The traps other students keep falling into on file processing and exception handling questions — taken from recent Cambridge IGCSE examiner reports and mark schemes — and how to avoid them.

✕Forgetting CLOSEFILE, or closing only one of several open files.
Examiner reports regularly note marks lost for missing CLOSEFILE statements.
Why it happens
Students focus on the reading/writing and treat closing as optional, or open two files but write only one CLOSEFILE.
How to avoid it
Every OPENFILE needs its own matching CLOSEFILE. Closing is where written data is saved and the file is released.
✕Using FOR WRITE when the task says to add to a file, wiping the existing data.
Why it happens
Students see 'write to the file' and pick WRITE without noticing the data must be kept.
How to avoid it
If the question says 'add', 'keep existing records' or 'do not delete', use FOR APPEND. FOR WRITE empties the file first.
✕Testing EOF after READFILE instead of before it, so the loop reads one line past the end.
Why it happens
Students put the EOF check at the bottom of the loop (post-test) rather than as the WHILE condition.
How to avoid it
Always loop WHILE NOT EOF("name") DO and READFILE inside it, so EOF is checked before each read.
✕Doing arithmetic or numeric comparison on a value read straight from a text file without converting it.
Why it happens
Lines from a text file are STRINGs, but they look like numbers, so students forget the conversion.
How to avoid it
Convert with STRING_TO_NUM before any calculation, and NUM_TO_STRING before writing a number to a text file.
✕On a random file, calling PUTRECORD straight after GETRECORD without SEEKing back, so the record is written to the wrong position.
Why it happens
Students do not realise GETRECORD advances the file position past the record just read.
How to avoid it
SEEK to the record number again immediately before PUTRECORD to overwrite the correct record.
✕Treating exception handling as a replacement for ordinary input validation (or vice versa, ignoring exceptions entirely).
Why it happens
Students learn TRY…EXCEPT and apply it everywhere, or rely only on IF checks and let conversions crash the program.
How to avoid it
Use validation for predictable conditions (e.g. a value in range) and exception handling for unpredictable run-time failures (e.g. bad type conversion, missing file).

File Processing and Exception Handling — Cambridge AS & A Level Computer Science 9618 Study Notes (2027-2029)

Mode

What it does

Use it to…

FOR READ

opens an existing file to read from the start

read data back

FOR WRITE

creates a new, empty file (overwrites any existing one)

start a fresh file

FOR APPEND

opens an existing file and writes at the end

add to existing data

OPENFILE "Data.txt" FOR READ // or FOR WRITE / FOR APPEND READFILE "Data.txt", Variable // read the next line into Variable WRITEFILE "Data.txt", Value // write one line CLOSEFILE "Data.txt" // close it (saves + releases)

OPENFILE "Students.txt" FOR APPEND WRITEFILE "Students.txt", NUM_TO_STRING(NewStudent.StudentID) WRITEFILE "Students.txt", NewStudent.Name WRITEFILE "Students.txt", NUM_TO_STRING(NewStudent.Mark) CLOSEFILE "Students.txt"

DECLARE Current : Student DECLARE Temp : STRING READFILE "Students.txt", Temp Current.StudentID ← STRING_TO_NUM(Temp) READFILE "Students.txt", Current.Name READFILE "Students.txt", Temp Current.Mark ← STRING_TO_NUM(Temp)

File type

Organisation

Access

Serial

records in arrival order (no ordering)

read from the start, one by one

Sequential

records ordered by a key field

still read in order, but easier to merge/search

Random

each record has a position / record number (often from a hashing algorithm)

direct access — jump straight to a record

SEEK "Stock.dat", 7 // move to record position 7 GETRECORD "Stock.dat", Item // read that record into Item Item.Quantity ← Item.Quantity + 10 SEEK "Stock.dat", 7 // re-seek: GETRECORD moved the position on PUTRECORD "Stock.dat", Item // write the record back to position 7

An exception is a run-time error — an abnormal event that happens while the program is running and that would otherwise make it stop/crash. Typical causes:

trying to open a file that does not exist;
dividing by zero;
converting non-numeric input (e.g. "hello") into a number.

WHILE NOT EOF("Prices.txt") DO READFILE "Prices.txt", Line TRY Price ← STRING_TO_NUM(Line) OUTPUT Price * 1.2 EXCEPT OUTPUT "Skipping invalid line: ", Line ENDTRY ENDWHILE

TYPE Student StudentID : INTEGER Name : STRING Mark : INTEGER ENDTYPE DECLARE NewStudent : Student INPUT NewStudent.StudentID INPUT NewStudent.Name INPUT NewStudent.Mark OPENFILE "Students.txt" FOR APPEND WRITEFILE "Students.txt", NUM_TO_STRING(NewStudent.StudentID) WRITEFILE "Students.txt", NewStudent.Name WRITEFILE "Students.txt", NUM_TO_STRING(NewStudent.Mark) CLOSEFILE "Students.txt"

DECLARE Current : Student DECLARE Temp : STRING OPENFILE "Students.txt" FOR READ WHILE NOT EOF("Students.txt") DO READFILE "Students.txt", Temp Current.StudentID ← STRING_TO_NUM(Temp) READFILE "Students.txt", Current.Name READFILE "Students.txt", Temp Current.Mark ← STRING_TO_NUM(Temp) IF Current.Mark >= 50 THEN OUTPUT Current.Name ENDIF ENDWHILE CLOSEFILE "Students.txt"

DECLARE ThisItem : StockItem OPENFILE "Stock.dat" FOR RANDOM SEEK "Stock.dat", 7 GETRECORD "Stock.dat", ThisItem ThisItem.Quantity ← ThisItem.Quantity + 10 SEEK "Stock.dat", 7 PUTRECORD "Stock.dat", ThisItem CLOSEFILE "Stock.dat"

DECLARE UserInput : STRING DECLARE Age, Result : INTEGER OUTPUT "Enter your age:" INPUT UserInput TRY Age ← STRING_TO_NUM(UserInput) Result ← 1000 DIV Age OUTPUT "Result = ", Result EXCEPT OUTPUT "Invalid input — please enter a non-zero number." ENDTRY

DECLARE NewMember : Member INPUT NewMember.MemberID INPUT NewMember.FullName INPUT NewMember.Active OPENFILE "Members.txt" FOR APPEND WRITEFILE "Members.txt", NUM_TO_STRING(NewMember.MemberID) WRITEFILE "Members.txt", NewMember.FullName WRITEFILE "Members.txt", NewMember.Active CLOSEFILE "Members.txt"

DECLARE Line : STRING DECLARE Price : REAL OPENFILE "Prices.txt" FOR READ WHILE NOT EOF("Prices.txt") DO READFILE "Prices.txt", Line TRY Price ← STRING_TO_NUM(Line) OUTPUT "Price with tax: ", Price * 1.2 EXCEPT OUTPUT "Skipping invalid line: ", Line ENDTRY ENDWHILE CLOSEFILE "Prices.txt"

DECLARE TheAccount : Account OPENFILE "Accounts.dat" FOR RANDOM SEEK "Accounts.dat", 42 GETRECORD "Accounts.dat", TheAccount TheAccount.Balance ← TheAccount.Balance + 50 SEEK "Accounts.dat", 42 PUTRECORD "Accounts.dat", TheAccount CLOSEFILE "Accounts.dat"

File Processing and Exception Handling

Detailed Study Notes

At a glance

What you’ll learn

Quick recap

Memorise this

How it’s examined

Take this whole topic with you

1Open, read and close a text file

2Write to a new file and append to it

3Write a RECORD to a file

4Read RECORDs back from a file

5Direct access to a random file (SEEK / GETRECORD / PUTRECORD)

6Exception handling for input and file access

File

Record

Serial file

Sequential file

Random (direct-access) file

READ mode

WRITE mode

APPEND mode

EOF (end of file)

Exception

Exception handling

TRY / EXCEPT (and FINALLY)

✕Forgetting CLOSEFILE, or closing only one of several open files.

✕Using FOR WRITE when the task says to add to a file, wiping the existing data.

✕Testing EOF after READFILE instead of before it, so the loop reads one line past the end.

✕Doing arithmetic or numeric comparison on a value read straight from a text file without converting it.

✕On a random file, calling PUTRECORD straight after GETRECORD without SEEKing back, so the record is written to the wrong position.

✕Treating exception handling as a replacement for ordinary input validation (or vice versa, ignoring exceptions entirely).

File Processing and Exception Handling

Detailed Study Notes

At a glance

What you’ll learn

Quick recap

Memorise this

How it’s examined

Take this whole topic with you

1Open, read and close a text file

2Write to a new file and append to it

3Write a RECORD to a file

4Read RECORDs back from a file

5Direct access to a random file (SEEK / GETRECORD / PUTRECORD)

6Exception handling for input and file access

File

Record

Serial file

Sequential file

Random (direct-access) file

READ mode

WRITE mode

APPEND mode

EOF (end of file)

Exception

Exception handling

TRY / EXCEPT (and FINALLY)

✕Forgetting CLOSEFILE, or closing only one of several open files.

✕Using FOR WRITE when the task says to add to a file, wiping the existing data.

✕Testing EOF after READFILE instead of before it, so the loop reads one line past the end.

✕Doing arithmetic or numeric comparison on a value read straight from a text file without converting it.

✕On a random file, calling PUTRECORD straight after GETRECORD without SEEKing back, so the record is written to the wrong position.

✕Treating exception handling as a replacement for ordinary input validation (or vice versa, ignoring exceptions entirely).