Stage 1·Core Language

Debugging & Reading Errors

Understand compiler errors and stack traces - the number one beginner survival skill.

12 min readBeginner

On this page

Here's a secret every professional knows: code breaks constantly. Errors aren't failures - they're the normal rhythm of programming. The difference between a frustrated beginner and a confident developer is simply the ability to read errors and fix them calmly. That's what this lesson builds.

The three kinds of errors

Three ways a recipe can go wrong

A compile error is like a recipe with a grammatical mistake - you can't even start cooking until it's fixed.
A runtime error is like the pot boiling over mid-cook - everything looked fine until it suddenly wasn't.
A logic error is like following every step perfectly but adding salt instead of sugar - it runs fine, but the result is wrong.

1. Compile errors: Java won't even start

The compiler catches these before your program runs. The most common cause is a tiny typo - a missing semicolon or brace:

System.out.println("Hello")   // ← missing semicolon

error: ';' expected
    System.out.println("Hello")
                               ^

The compiler tells you the file, the line, and often points a ^ right at the problem. Read it literally: "I expected a ; here." Add the semicolon and you're done.

Fix the FIRST error first

One missing brace can trigger a cascade of dozens of errors. Don't panic - fix the top error, then recompile. Often that one fix clears many of the others.

2. Runtime errors: crashes and stack traces

These happen while the program runs. Java stops and prints a stack trace - a report of what went wrong and where. It looks scary but is incredibly helpful.

public class Boom {
    public static void main(String[] args) {
        int[] nums = { 1, 2, 3 };
        System.out.println(nums[5]);  // no index 5!
    }
}

Exception in thread "main"
java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 3
    at Boom.main(Boom.java:4)

Read a stack trace from the top:

The exception type - ArrayIndexOutOfBoundsException tells you the category of problem (you reached outside an array).
The message - Index 5 out of bounds for length 3 tells you exactly what happened.
The location - Boom.java:4 tells you where: file Boom.java, line 4.

Go to that line, and the fix is usually obvious.

Common exceptions you'll meet

Exception	Usually means…
`NullPointerException`	You used something that was `null` (empty)
`ArrayIndexOutOfBoundsException`	You accessed an invalid array index
`NumberFormatException`	You tried to turn non-numeric text into a number
`ArithmeticException`	Illegal math, like dividing an int by zero

The infamous NullPointerException

A NullPointerException (NPE) means you tried to use a variable that points to nothing (null) - like calling name.length() when name was never given a value. It's the most common runtime error in Java. Check what could be null on the reported line.

3. Logic errors: it runs, but it's wrong

The trickiest kind: no crash, no error message - just a wrong answer. The program does exactly what you told it, which wasn't what you meant.

int total = 0;
for (int i = 1; i < 5; i++) {   // stops at 4, not 5!
    total += i;
}
System.out.println(total);  // 10, but you wanted 1+2+3+4+5 = 15

Here i < 5 should be i <= 5. No error appears - you catch it by checking whether the output matches your expectation.

How to debug, calmly

Read the error message - it names the type, the reason, and the line. Read it literally.
Go to the line it points to and look closely.
Print things out. Add System.out.println(...) to inspect values at different points - the humble print statement is a debugging superpower.
Use a debugger. IDEs let you set a breakpoint and step through code line by line, watching variables change. Learn this early - it's magic.
Search the exact error message. You are never the first person to hit it.

Errors are your teachers

Reframe every error as the computer helping you by pointing out a problem precisely. The best developers aren't the ones who never see errors - they're the ones who read them without fear and fix them quickly.

Quick check

A stack trace ends with 'at Order.java:17'. Where should you look first?

Key takeaways

Errors are a normal part of programming, not a sign of failure.
Compile errors stop compilation (often typos); fix the FIRST one, then recompile.
Runtime errors print a stack trace: read the exception type, message, and file:line from the top.
Common exceptions include NullPointerException, ArrayIndexOutOfBoundsException, and NumberFormatException.
Logic errors run without complaint but give wrong results - catch them by checking output.
Debug by reading the message, printing values, and using your IDE's debugger and breakpoints.

That's Stage 1 complete! You can now store data, make decisions, loop, write methods, handle text and arrays, and read errors. Next, Stage 2 introduces the big idea that organizes all serious Java code: object-oriented programming.