Brewlearn Get the app
☕ Java Foundations · Beginner

Compile vs runtime errors in Java

Syntax/type errors caught by javac vs exceptions thrown while running.

🧩 The mysterySome bugs are caught before your program even starts. Others wait silently until a real user hits them. Which kind would you rather have?

Compile-time errors

javac finds these before anything runs: syntax mistakes like a missing ;, unknown names, and type mismatches. No .class file is produced, so nothing runs at all.

int x = 5          // missing ;
System.out.printn("hi"); // no such method
int y = "five";    // wrong type
🔮 Predict it

Your turn

What happens?

System.out.Println("Hi");
  1. Hi
  2. Compile error
  3. Throws an exception
Show the answer

Compile error. Java is case-sensitive, and there's no method called Println. javac reports cannot find symbol and the program never starts.

Runtime errors

Here the code is valid, compiles and starts. Then something goes wrong while it runs, and the JVM throws an exception such as ArithmeticException or ArrayIndexOutOfBoundsException. Output printed before the problem still appears.

🔮 Predict it

Your turn

What happens?

int zero = 0;
System.out.println("start");
System.out.println(10 / zero);
  1. Prints start, then throws ArithmeticException
  2. Compile error
  3. start Infinity
Show the answer

It compiles fine, prints start, then crashes. The compiler only checks types. It can't know that zero will be 0, so integer division by zero is caught at runtime.

🤔 Think first

Why not catch it earlier?

int[] scores = {90, 85}; and then scores[2]. Obviously wrong! Why doesn't javac complain?

Think about it, then reveal the answer

Array indexes are checked when the code runs. Indexes usually come from variables and user input, so the compiler generally can't know them. The JVM checks every access and throws ArrayIndexOutOfBoundsException.

⚠️ The trap

"It compiled, so it works"

Compiling only proves the code is valid Java with consistent types. It says nothing about bad values, wrong logic or missing files. Compiled code still needs to be run and tested.

💼 In the real world

In real projects

A compile error costs you seconds on your laptop. A runtime error might show up only for certain inputs, at 3 a.m., in production, in front of customers. That's why teams love catching bugs at compile time.

Key takeaways

  1. Compile errors: no .class file is produced, nothing runs
  2. Runtime errors: the program starts, then throws an exception
  3. Catching a bug at compile time is cheaper than in production
🤯 Did you know?

In 1947, engineers on the Harvard Mark II found a real moth stuck in a relay. They taped it into their logbook as the "first actual case of bug being found".

Practice questions

Which of these problems shows up only at runtime?

  1. Assigning a String to an int variable
  2. Writing system.out instead of System.out
  3. Forgetting a closing brace
  4. Dividing an int by a variable that happens to be zero
Check your answer

Dividing an int by a variable that happens to be zero. The compiler can't know a variable's value ahead of time, so int division by zero is detected when it happens, as an ArithmeticException.

What does this print?

System.out.printn("Hi");
  1. Hi
  2. Throws NoSuchMethodError
  3. Nothing is printed
  4. Compile error
Check your answer

Compile error. There's no method called printn, so javac reports "cannot find symbol". The program never starts.

Next: javac, java, jshell. Three commands to build and run Java, plus a shortcut that skips the compile step.