How is an event driven application tested and debugged, and how does exception handling stop run-time errors from crashing it?
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.
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 test and debug an event driven application and to use exception handling to make it robust. You must describe a test strategy (test data, test plans, the kinds of testing), the debugging tools an IDE provides (breakpoints, stepping, watches, the call stack), and how a try ... catch structure detects and handles run-time errors so the program does not crash. These ideas build on the AS 1 testing topic and recur in the A2 project.
The answer
Testing an application
In an event driven program, each event handler is a unit that should be tested with valid and invalid input, and the application should be tested with controls used in different orders, because the user controls the flow.
Debugging tools
Exception handling and robustness
A robust program keeps running sensibly even with bad input or unexpected conditions. Exception handling is the mechanism that allows this: an exception is a run-time error (a bad conversion, a missing file, a divide by zero) that would otherwise stop the program. A try ... catch structure puts the risky code in the try block; if an exception occurs, control jumps to the catch block, which handles it (for example by showing a clear message), so the program continues.
try
qty = toInteger(txtQty.Text)
price = total / qty // could divide by zero
catch
lblStatus.Text = "Enter a valid, non-zero quantity"
end try
Worked example: debugging and hardening a handler
Examples in context
Example 1. A currency converter. The amount field is validated as a number, but the conversion is still wrapped in a try/catch so an unexpected parse failure shows "Enter a valid amount" rather than crashing. During development a breakpoint on the conversion line and a watch on the entered value quickly exposed a case where a trailing space broke the parse, which was then fixed.
Example 2. A file-backed notes app. Saving notes is wrapped in exception handling so a full disk or a locked file produces a clear warning, keeping the app running. Each handler (new note, save, delete) was unit tested with valid and invalid input, then the app was system tested with the buttons used in many different orders, reflecting the event driven flow.
Try this
Q1. Distinguish between testing and debugging. [2 marks]
- Cue. Testing finds that a fault exists by running the program against planned data; debugging locates and fixes the fault.
Q2. Name one IDE debugging tool and explain how it helps find a fault. [2 marks]
- Cue. For example a breakpoint pauses execution at a chosen line so the programmer can inspect the program's state and isolate where the fault begins.
Q3. State what a try block and a catch block are each responsible for in exception handling. [2 marks]
- Cue. The try block contains the risky code that might raise an exception; the catch block handles the exception if one occurs, so the program does not crash.
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 marksDescribe three tools provided by an integrated development environment (IDE) to help a programmer debug a program, explaining how each helps.Show worked answer →
An IDE provides debugging tools that let the programmer examine a running program. Three examples:
A breakpoint marks a line at which execution pauses, so the programmer can stop the program at a chosen point and inspect its state rather than letting it run to the end. This isolates where a fault begins.
Stepping (step into, step over, step out) runs the program one statement at a time, so the programmer can follow the exact path of execution and see which branch is taken and which loop iterations run. This reveals control-flow faults.
A watch (or inspecting variables) shows the current value of chosen variables as the program runs or while paused, so the programmer can see where a value becomes wrong. Other valid tools include the call stack, the output/console window, and the immediate window for evaluating expressions.
Markers reward three genuine debugging tools, each with a correct explanation of how it helps the programmer find a fault.
CCEA 20215 marksExplain what exception handling is and how a try and catch structure makes a program more robust, using an example.Show worked answer →
An exception is a run-time error that would normally stop the program, such as dividing by zero, an invalid number conversion, or a missing file. Exception handling is a mechanism that lets the program detect and respond to such an error instead of crashing.
A try and catch structure puts the risky code in a try block; if an exception occurs there, control jumps to the catch block, which handles the error (for example by showing a clear message and letting the user try again). For example:
try
age = toInteger(txtAge.Text)
catch
lblStatus.Text = "Please enter a whole number"
end try
Here, if the user types "abc", the conversion fails and raises an exception; the catch block reports the problem instead of the program crashing. This makes the program robust: it keeps running and behaves sensibly even with bad input or unexpected conditions.
Markers reward defining an exception as a run-time error, the try-runs-risky-code and catch-handles-it mechanism, a sensible example, and the link to robustness (the program does not crash).
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.
- 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.
- 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.
- 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.
Sources & how we know this
- CCEA GCE Software Systems Development specification — CCEA (2016)