Here's the thing nobody tells you when you start coding: you will never write a perfect program on the first try. Not you, not your teacher, not the engineers who built the app you're using right now. Every programmer spends huge chunks of their time hunting down bugs — and the first skill in hunting a bug is knowing what kind of bug you're even looking for.

Think of it like being a doctor. If a patient walks in, you don't just say "something's wrong" — you first work out: is this a broken bone (obvious, visible, stops them walking), an infection (they seem okay but something's off internally), or a sudden collapse (they were fine, then suddenly weren't)? Each needs a totally different fix. Programming errors work exactly the same way:

Cambridge IGCSE 0478 tests this constantly, especially in Paper 2, using trace tables and "dry runs" of code. Get comfortable with the three categories and the exact vocabulary examiners want, and this becomes one of the easiest topics to pick up marks on.

A syntax error is an error that breaks the grammatical rules of a programming language and stops it from running at all. Programming languages are strict about grammar in a way English isn't — English lets you get away with a missing comma, but Python will refuse to even start if you forget a colon.

Think of syntax like the rules of a board game. If the rulebook says "you must roll the dice before moving," and you try to move without rolling, the game simply won't let you take that turn. It doesn't matter how clever your strategy is — you broke the rule of the game itself, so nothing proceeds.

Let's look at a real example. Below is a Python program meant to generate a username from a person's first and last name. It's riddled with syntax errors — see if you can spot all four before reading on.

def generate_username(first_name, last_name)          # ← missing colon
   username = f"{first_name[0]}{last_name[0]}{last_name[:3]}"
   return username

def main():
   first_name = imput("Enter your first name: ")     # ← "imput" not "input"
   last_name = input("Enter your last name: ")
   usdrname = generate_username(first_name, last_name)  # ← typo, variable never matches
   print(f"Here's a suggested username: {username}")

main                                                   # ← missing parentheses, function never called

Here's the corrected version — notice every fix is small, but each one was blocking the whole program from running:

def generate_username(first_name, last_name):
   username = f"{first_name[0]}{last_name[0]}{last_name[:3]}"
   return username

def main():
   first_name = input("Enter your first name: ")
   last_name = input("Enter your last name: ")
   username = generate_username(first_name, last_name)
   print(f"Here's a suggested username: {username}")

main()

A logic error is where the code is syntactically correct and runs perfectly fine, but it produces an incorrect output or result. This is the trickiest error type because the program doesn't announce it — no crash, no error message, nothing. It just quietly gives you the wrong answer, and you might not notice unless you check the output carefully.

Imagine following a recipe that says "bake for 25 minutes at 180°C" when it should say 350°C. You'll follow every instruction perfectly, the oven will run, nothing will crash — but you'll pull out an undercooked cake. That's exactly what a logic error feels like in code: everything executes, but the underlying instruction was wrong.

How do you find logic errors? The main tool is the trace table — a table where you track the value of every variable, line by line, as the program executes. If the values diverge from what you expect at some point, that's exactly where your bug is hiding.

Let's examine a real case. This function is meant to calculate the area of a rectangle, but reject any length or width that isn't positive:

def calculate_area(length, width):
   if length < 0 or width < 0:                     # ← the bug is here
      raise ValueError("Length and width must be positive values.")
   area = length * width
   return area

The team tested it with two cases:

Test 2 exposes the logic error. A width of 0 should have been rejected as "not positive," but the code let it through and calculated an area of 0.00 anyway.

This is a perfect example of why logic errors are so dangerous in the real world — a program handling money, medicine dosages, or safety systems could quietly accept a value it should have blocked, and nobody would know until something went wrong downstream.

A runtime error is where an error causes a program to crash while it is running. The code was grammatically fine (it passed the syntax check and started running), but partway through execution, it hits a situation it simply cannot handle — and the whole thing stops abruptly.

Think of it like driving a car that starts up perfectly fine (no syntax error there — the engine runs) but then hits a pothole so severe it blows a tyre and the car grinds to a halt. Nothing was wrong with starting the engine; the failure only happened once you were moving and hit a specific, unhandled situation.

Let's return to the rectangle area program, now fully corrected of its logic error, and test it with an unusual input:

def calculate_area(length, width):
   if length < 0 or width < 0:
      raise ValueError("Length and width must be positive values.")
   area = length * width
   return area

def main():
   try:
      length = float(input("Enter the length of the rectangle: "))
      width = float(input("Enter the width of the rectangle: "))
      area = calculate_area(length, width)
      print(f"The area of the rectangle is approximately {area:.2f} square units.")
   except ValueError as error:
      print(f"Error: {error}")

main()

Test 2 reveals the runtime error. Typing "abc" where a number is expected causes float(input(...)) to raise an error that isn't a ValueError from the rectangle logic — it's a conversion error the try/except block wasn't built to catch and recover from repeatedly. The program crashes instead of asking the user to try again.

while True:
   try:
      length = float(input("Enter the length of the rectangle: "))
      width = float(input("Enter the width of the rectangle: "))
      area = calculate_area(length, width)
      print(f"The area of the rectangle is approximately {area:.2f} square units.")
      break   # Exit the loop if successful
   except ValueError as error:
      print(f"Error: {error}")
      print("Please enter positive values for length and width.")

Notice the fix isn't a one-line tweak like the syntax and logic examples — sometimes a runtime error needs a structural change, like adding a loop so the program recovers gracefully instead of dying.

This is the single most useful table in this whole chapter — if you can rebuild this from memory, you're set for any "identify the error type" question.

Algorithmic thinking is the process of creating step-by-step instructions in order to produce a solution to a problem. It's the skill that sits underneath every single line of code you'll ever write — before you can code a solution, you need to think it through as a precise sequence of steps.

Algorithmic thinking leans on two big ideas you've probably met before:

Once every step has been identified through decomposition and abstraction, you can write a precise set of rules (an algorithm) that solves the problem reliably, every single time.

Writing algorithms under exam pressure is genuinely one of the hardest parts of this course — not because the logic is impossible, but because it's easy to lose track of what you're doing halfway through. Here's a practical approach that examiners specifically recommend:

A worked example of a plan for "read 30 students' marks, calculate their grade, and output a summary" might look like:

Part 1: Declare and initialise variables
Part 2: Loop to input marks for each subject
Part 3: Allocate grades for each student's subject
Part 4: Include a loop to repeat for all 30 students
Part 5: Output all necessary data

What Examiners Are Really Looking For

• Correct identification of the error type using the correct terminology
• Precise location of the error (the exact line or expression)
• A clear explanation of the impact on the program's behaviour or output
• A working, testable fix — not just "add code here"
• Use of proper trace table structure when tracing variables
• Algorithms that use the exact variable names and data given in the question