Programming Error Types: Syntax, Runtime, Logic

Section 1

Quick Answer

Error types are the main categories of program mistakes: syntax errors (the code is written incorrectly and won't run), runtime errors (the program crashes while running), and logic errors (the program runs but gives the wrong answer). Reach for this concept when a problem asks you to CLASSIFY a failure rather than fix it — decide whether the code fails to run, crashes mid-run, or runs but is wrong. The cue separating it from Debugging is that the answer is a category name, not a corrected line of code.

Section 2

Why This Matters

Students debug faster when they can name the kind of error they are dealing with. Error types give structure to debugging instead of treating all bugs as the same.

Section 3

Intuitive Explanation

Picture three different ways a program can let you down. First, it won't even start: you left out a closing bracket or misspelled a keyword, so the parser stops you before anything runs — that is a syntax error. Second, it starts fine but blows up partway through, like dividing by zero or reading a list past its end — that is a runtime error. Third, it runs all the way to the end without complaint and quietly hands you the wrong answer, usually because you used the wrong formula or condition — that is a logic error.

The whole value of these categories is that each one points to a different debugging move. A syntax error tells you to fix the spelling or structure of the code. A runtime error tells you to trace where execution died and what input triggered it. A logic error is the sneaky one: nothing looks broken, so you have to check the reasoning against expected output. Naming the category first is what turns aimless poking into a targeted fix.

This is the step BEFORE debugging, not debugging itself. Debugging is the full hunt-and-repair; Error Types is just the diagnosis that tells the hunt where to begin. So when a question asks what kind of error you are looking at, the answer is one of these three labels — not a patched line of code.

Core idea

Different bugs need different debugging strategies.

Section 4

When to Use

Use Error Types when a problem hands you a broken program — a compiler complaint, a crash, or a wrong result — and asks you to say WHICH category of mistake it is. Look for the structural cue that you only need a label: does the code refuse to run (syntax), blow up while running (runtime), or run cleanly but produce the wrong answer (logic)? Do not reach for Error Types when the task is to actually locate and repair the bug (that is Debugging) or to design cases that expose bugs (that is Testing).

Pro tip

Ask three questions: Does the code run at all? Does it crash while running? Does it run but give the wrong output? Your answer usually tells you the error type.

Section 5

How to Recognize It

Before using Error Types, check whether the task is to CLASSIFY a mistake into syntax / runtime / logic, not to hunt it down or repair it. These questions test the same recognition move from a few angles.

Am I being asked which CATEGORY of error this is, rather than to fix it?

If the answer is a label like 'syntax error' or 'logic error', it is Error Types. If the answer is a corrected line of code, you are doing Debugging instead.
Can I decide by asking when the failure shows up — won't run, crashes mid-run, or runs but is wrong?

Failing to compile or a parser complaint signals a syntax error; a crash during execution (like divide-by-zero) signals a runtime error; correct execution with a wrong result signals a logic error.
What is the nearest confusion?

Debugging is the trap: it is the whole process of locating and fixing a bug. Error Types is only the naming step that tells Debugging where to look. If the prompt says 'find and fix', it is Debugging.
Does the prompt give me a symptom — an error message, a crash, or a wrong output — to interpret?

A symptom you must match to a category is the evidence for Error Types. With no broken behavior to classify, the term is probably just vocabulary.
What would make this NOT Error Types?

If the task asks you to write test cases that catch mistakes (Testing) or to actually correct the program (Debugging), the category label is no longer the point — switch concepts.

Section 6

Error Types vs Debugging vs Testing vs Edge Cases

These four get mixed up because they all live near 'something is wrong with the program.' The deciding question is the job: Error Types only wants a CATEGORY name, while the others want you to find, verify, or stress the code.

Error Types vs Debugging vs Testing vs Edge Cases
Type	Meaning	Key test	Formula	Example
Error Types	Use this when you are handed a broken program and asked which CATEGORY the mistake falls in: syntax (won't run), runtime (crashes mid-run), or logic (runs but gives the wrong answer). The deciding question is: am I labeling what kind of mistake this is, not finding or fixing it?	Am I labeling what KIND of mistake this is — syntax, runtime, or logic — rather than locating or repairing it?	$\text{errors} = \{\text{syntax}, \text{runtime}, \text{logic}\}$	A missing closing bracket is a syntax error; dividing by zero is a runtime error; using the wrong formula is a logic error.
Debugging	Fits when the task is to actually track down and repair a bug — form a hypothesis, test it, and correct the offending line — not just name its category.	Use when the prompt asks you to find the cause and fix the code, not classify it.	$\text{symptom} \rightarrow \text{hypothesis} \rightarrow \text{fix}$	The program prints 'Hello Worl'; you trace the loop bound and correct it to print 'Hello World'.
Testing	Fits when the task is to run the program on known inputs and check the outputs match what is expected, to reveal whether bugs exist.	Use when you are designing or running input/output checks rather than naming a fault.	$\text{pass} \iff o_{\text{expected}} = o_{\text{actual}}$	Running a divide function on $(10,2)$ , $(0,5)$ , $(-6,3)$ and comparing each result to the expected value.
Edge Cases	Fits when the task is to choose the unusual or boundary inputs — empty, zero, minimum, maximum — that sit at the limits of what the program must handle.	Use when picking boundary or corner inputs that ordinary cases would miss.	$x \in \{\,\emptyset,\ 0,\ \text{min},\ \text{max}\,\}$	Besides a normal five-item list, also testing an empty list, a one-item list, and a huge value.

Error Types

Meaning: Use this when you are handed a broken program and asked which CATEGORY the mistake falls in: syntax (won't run), runtime (crashes mid-run), or logic (runs but gives the wrong answer). The deciding question is: am I labeling what kind of mistake this is, not finding or fixing it?
Key test: Am I labeling what KIND of mistake this is — syntax, runtime, or logic — rather than locating or repairing it?
Formula: $\text{errors} = \{\text{syntax}, \text{runtime}, \text{logic}\}$
Example: A missing closing bracket is a syntax error; dividing by zero is a runtime error; using the wrong formula is a logic error.

Debugging

Meaning: Fits when the task is to actually track down and repair a bug — form a hypothesis, test it, and correct the offending line — not just name its category.
Key test: Use when the prompt asks you to find the cause and fix the code, not classify it.
Formula: $\text{symptom} \rightarrow \text{hypothesis} \rightarrow \text{fix}$
Example: The program prints 'Hello Worl'; you trace the loop bound and correct it to print 'Hello World'.

Testing

Meaning: Fits when the task is to run the program on known inputs and check the outputs match what is expected, to reveal whether bugs exist.
Key test: Use when you are designing or running input/output checks rather than naming a fault.
Formula: $\text{pass} \iff o_{\text{expected}} = o_{\text{actual}}$
Example: Running a divide function on $(10,2)$ , $(0,5)$ , $(-6,3)$ and comparing each result to the expected value.

Edge Cases

Meaning: Fits when the task is to choose the unusual or boundary inputs — empty, zero, minimum, maximum — that sit at the limits of what the program must handle.
Key test: Use when picking boundary or corner inputs that ordinary cases would miss.
Formula: $x \in \{\,\emptyset,\ 0,\ \text{min},\ \text{max}\,\}$
Example: Besides a normal five-item list, also testing an empty list, a one-item list, and a huge value.

Section 7

Formula & Notation

\text{errors} = \{\text{syntax}, \text{runtime}, \text{logic}\}

Programming errors are commonly classified as syntax violations caught by the parser, runtime failures triggered during execution, and logic defects that preserve execution but violate correctness.

Section 8

Worked Examples

Example 1 — Recognize the model

Easy

Problem

A class sees this computing situation: students plan a small app, write pseudocode, test edge cases, document decisions, and revise the design after feedback. How should a student decide whether Error Types is the right model?

Solution

Identify the target of the reasoning.

The target might be a problem, data representation, code state, system component, user need, or stakeholder.
List the process or relationship that matters.

Error Types is useful when the problem asks for a software-design explanation with requirement, artifact, user need, test evidence, maintenance concern, and tradeoff stated.
Apply the recognition test: Am I reasoning about how a software solution is specified, communicated, tested, changed, or used by people?

This separates error types from programming syntax and algorithm only.
State the evidence that would prove the answer.

A trace, test, diagram, input-output pair, or impact argument prevents a vague answer.

Answer

Use Error Types only if the task is asking for a software-design explanation with requirement, artifact, user need, test evidence, maintenance concern, and tradeoff stated and the situation passes the recognition test. Otherwise, choose the nearby model that better matches the computing structure.

Takeaway: Model choice comes before definitions. The same words can belong to different CS ideas depending on the problem structure.

Example 2 — Avoid the vocabulary trap

Standard

Problem

A student says, "This prompt contains the word design, so I should use error types." Explain why that shortcut is risky.

Solution

Treat the word as a clue, not proof.

CS vocabulary overlaps across problem solving, programming, data, systems, design, and impact questions.
Check whether the target and process match Error Types.

The computing structure decides the model.
Compare with Programming syntax and Algorithm only.

Syntax makes code run; software design decides what should be built and how it will be checked. An algorithm solves a core task, but software design includes users, interfaces, documentation, tests, and maintenance.
State what the final result would mean.

If the final result would not mean a software-design explanation with requirement, artifact, user need, test evidence, maintenance concern, and tradeoff stated, the model is probably wrong.

Answer

The shortcut is risky because design can appear in several related CS models. The student must first show that the task answers "Am I reasoning about how a software solution is specified, communicated, tested, changed, or used by people?" with yes.

Takeaway: A CS thinking concept is a reasoning tool, not just a vocabulary match.

Example 3 — Write the computing conclusion

Application

Problem

After solving a Error Types problem, a student writes only a definition. What should be added to make the answer useful?

Solution

Name the specific case.

The answer should identify the input, data, program state, system component, user, or stakeholder being described.
Show the process or evidence.

A trace, test, example, diagram, or tradeoff explains why the concept applies.
Connect the result to the goal.

The final sentence should say how the concept helps solve, test, design, represent, protect, or evaluate the computing situation.
Mention limits or edge cases.

Computing answers are stronger when they state where the method might fail, scale poorly, exclude users, or require a different design.

Answer

A complete answer should say what error types controls in the specific situation, include evidence such as a trace or test, and state any condition needed for the model to apply.

Takeaway: The final explanation is part of CS thinking, not an optional sentence after the term.

Section 9

Common Mistakes

Common slip-up

Calling every wrong answer a syntax problem even when the code runs

The right idea

Fix this by naming the input, process, output, evidence, and checking "Am I reasoning about how a software solution is specified, communicated, tested, changed, or used by people?" before using the concept.

Common slip-up

Fixing one runtime crash without checking whether a deeper logic problem remains

The right idea

Fix this by naming the input, process, output, evidence, and checking "Am I reasoning about how a software solution is specified, communicated, tested, changed, or used by people?" before using the concept.

Common slip-up

Ignoring compiler or interpreter messages that already identify the error category

The right idea

Fix this by naming the input, process, output, evidence, and checking "Am I reasoning about how a software solution is specified, communicated, tested, changed, or used by people?" before using the concept.

Common slip-up

Using error types from a keyword alone

The right idea

Signal words like design, test, document only point to a possible model; the computing structure must match too.

Section 10

Mini Practice

Try these on your own. Tap Reveal when you want to check.

Which error type is this: a Python program runs fully and prints an average of 0 for the list [4, 8, 12], because the code divides the total by len(numbers) + 1 instead of len(numbers)?

Hint: Did the program crash, refuse to run, or finish and give a wrong answer?
Classify this: the interpreter refuses to start the program at all and reports an unexpected end of input on the line def add(a, b. Syntax, runtime, or logic?

Hint: Did any code execute before the complaint?
Why is this a contrast case (Debugging, not Error Types): given a program that prints 'Hello Worl', the prompt asks you to find why the last letter is dropped and correct the loop so it prints 'Hello World'.

Hint: Is the expected answer a category name or a corrected line?

Want the full set?

50 practice questions for this concept — free to try, every one with a complete worked solution showing the why, not just the answer.

Practice this concept → Take a mastery check

Section 11

Frequently Asked Questions

What are the error types in simple terms?

They are the three main categories a program mistake can fall into. A syntax error means the code is written incorrectly and won't even run — like a missing closing bracket. A runtime error means the program starts but crashes partway through — like dividing by zero. A logic error means the program runs to the end without crashing but produces the wrong answer — like using the wrong formula. The concept is about naming which of these three you are looking at.

How do I know a problem wants Error Types rather than Debugging?

Ask: am I labeling what KIND of mistake this is, or being asked to fix it? If the expected answer is a category name — 'that's a syntax error' — it's Error Types. If the expected answer is a corrected line of code or the located cause, it's Debugging. A quick test on a snippet: if it refuses to run it's syntax, if it blows up while running it's runtime, if it runs but the output is wrong it's logic — and naming that is all the task wants.

How do I tell a runtime error from a logic error?

Both happen while the program is running, which is why they get confused, but a runtime error stops the program — it crashes, like a divide-by-zero or an out-of-range index. A logic error never crashes: the program finishes normally and just gives the wrong answer, like averaging by dividing by the wrong count. The deciding question is whether the program halts with a failure (runtime) or completes and lies (logic).

What is the most common mistake with Error Types?

Calling every wrong answer a 'syntax problem' even when the code actually ran. If the program executed at all, the mistake cannot be a syntax error — syntax errors stop it from running in the first place. Check first whether the code ran: if it ran and crashed it's runtime, if it ran and produced a wrong result it's logic. Another trap is fixing one runtime crash and assuming the program is correct, when a logic error may still remain underneath.

Section 12

Learning Path

← Before

Debugging

Error Types

You are here

Next →

Testing

Before this, students should be comfortable with Debugging. This page focuses on the recognition cue: Am I reasoning about how a software solution is specified, communicated, tested, changed, or used by people? That cue connects earlier computing descriptions to later problem solving because students first choose the model, then choose the representation, code, test, diagram, or explanation. After this, Testing become easier to recognize.

Section 13