The big idea: An exception is a problem that appears while the program is running — not a mistake in the code's grammar.
Without handling, the program simply stops. With handling, it can say what went wrong and carry on.
Unexpected input
- Letters typed where a number was wanted
- An empty answer, or a date that does not exist
- The commonest source, because people are the source
Resource unavailable
- A file that is missing, or locked by something else
- A network or database that does not respond
- Nothing is wrong with your code — the world changed
Logic errors
- Dividing by a value that turned out to be zero
- Reading past the end of a list
- The code ran, but on values nobody planned for
Free preview
This is the free notes preview
You're reading the free notes. Aimnova Pro unlocks the full study experience — and you can try it with your first topic free to keep:
- FlashcardsLock in vocabulary and key terms with spaced repetition.
- Practice questionsAnswer exam-style questions and get instant AI marking.
- Mock exams & past-paper vaultSit full mocks and see exactly how examiners award marks.
- Personalised study planA daily plan built around your exam date and weak areas.
try — the risky part
except — what to do about it
finally — always, either way
Java says catch
Never catch everything and say nothing: A bare except that silently ignores the problem is worse than no handling at all.
The program appears to work while producing wrong results, and the cause is now invisible.
Practice with real exam questions
Answer exam-style questions and get AI feedback that shows you exactly what examiners want to see in a full-marks response.
Validate first
- Check before acting — is the list empty? is the divisor zero?
- Right when you can reasonably predict the problem
- Reads clearly, and costs nothing when all is well
- Cannot cover everything: a file can vanish between the check and the read
Handle the exception
- Let it happen, and deal with it when it does
- Right when the problem is outside your control
- The only option for files, networks and databases
- Needs a specific message, or it tells the user nothing
Real programs do both: Validate the things you can predict — an empty field, a number out of range.
Handle the things you cannot — a missing file, a network that stops answering. Neither one alone is enough.
Why it matters beyond tidiness: A crash loses whatever the user was doing, and an unhandled error message can reveal file paths and internal details that help an attacker.
Handling exceptions is partly a security measure.
How this is tested — you must name the failure, the construct that catches it, and what the user is told. It comes up two ways:
Paper 2 — working with code
- Describe exception handling, 3-5 marks
- Add handling to a given fragment
- Name the points of failure in a program
Paper 2 — the algorithmic-thinking question
- Identify what could fail, with no code shown
- Say what the program should do about it
The classic trap: Wrapping everything in one try and printing "an error occurred". Marks come from specific handling: which failure, which except, and a message the user can act on.
A program reads a class list from a file and calculates the average mark. Describe the points of failure and how each should be handled.
Model answer plan
See the mark-by-mark plan — for / against / judgement, with marking guidance — in study mode.