Debugging & Fehler lesen
Verstehe Compiler-Fehler und Stack-Traces - die wichtigste Überlebensfähigkeit für Anfänger.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
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
- 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 semicolonerror: ';' 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 -
ArrayIndexOutOfBoundsExceptiontells you the category of problem (you reached outside an array). - The message -
Index 5 out of bounds for length 3tells you exactly what happened. - The location -
Boom.java:4tells you where: fileBoom.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 = 15Here 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.