Compile-Time vs Runtime Errors in Java

A compile-time error is one the compiler refuses to produce bytecode for. A runtime error is one that compiles cleanly and only misbehaves once the code executes. The dividing line is not about severity — it is about whether the compiler can prove the problem at translation time.

javac catches a lot: type mismatches, missing returns on a value-returning method, unassigned local variables, unreachable statements, misspelled method names, arguments that do not match any overload, and the use of a variable before its definite assignment point. It also catches a small class of runtime-looking errors statically, such as division by a literal zero, which it rejects outright.

public class Main {
    public static void main(String[] args) {
        int x = 10;
        int y = zero();
        System.out.println("this compiles fine, but blows up at run time:");
        try {
            System.out.println(x / y);
        } catch (ArithmeticException e) {
            System.out.println("caught: " + e.getClass().getSimpleName()
                    + " - " + e.getMessage());
        }

        String s = null;
        try {
            System.out.println(s.length());
        } catch (NullPointerException e) {
            System.out.println("caught: " + e.getClass().getSimpleName());
        }
    }

    static int zero() {
        return 0;
    }
}

Note why the divisor is produced by a method rather than written as a literal: a literal zero is a compile-time constant, so javac would reject the program before it ever ran, which would not illustrate the point. Once the zero comes from anywhere the compiler cannot see, the division is accepted and the ArithmeticException surfaces at run time. The same is true of the null dereference: the compiler has no idea that s is null because the assignment is two lines above, so it happily compiles a call to length on it.

The practical takeaway for interviews: compilation guarantees type correctness, not correctness of values. Null dereferences, division by zero, array index errors, failed casts and every checked exception live entirely in the runtime category, and defensive coding plus tests are the only protection.

The distinction here is between exceptions the compiler insists you handle and exceptions it lets you ignore. Every exception in Java derives from Throwable, and the two branches that matter for everyday code are Exception and RuntimeException. RuntimeException and its subclasses are unchecked: the compiler lets them propagate without any declaration. ArithmeticException, NullPointerException, IllegalArgumentException, ClassCastException and IndexOutOfBoundsException all live here. The design rationale is that unchecked exceptions signal a programming error rather than a recoverable condition, so forcing every caller into a try-catch would be noise.

Everything else that extends Exception but not RuntimeException is checked: IOException, SQLException, ParseException, ClassNotFoundException. When a method may throw a checked exception, the compiler requires either that the call site catches it or that the method declares it in its throws clause. That is the mechanism by which the language forces you to think about failure at every call boundary.

import java.io.IOException;

public class Main {
    public static void main(String[] args) {
        // The compiler refuses this call unless IOException is handled or declared.
        try {
            readFile();
        } catch (IOException e) {
            System.out.println("checked exception   : " + e.getClass().getSimpleName());
        }

        try {
            int[] data = new int[2];
            System.out.println(data[5]);
        } catch (ArrayIndexOutOfBoundsException e) {
            System.out.println("unchecked exception : " + e.getClass().getSimpleName());
        }
    }

    static void readFile() throws IOException {
        throw new IOException("file missing");
    }
}

One nuance that trips people up: the compiler only enforces handling of checked exceptions that are declared in the throws clause of the method you are calling. An unchecked exception can always propagate from any method without being declared, so a method that crashes with a NullPointerException gives the caller no compile-time hint at all. When you write a library, declare the checked exceptions you can reasonably handle, keep unchecked ones for genuine programming errors, and avoid the anti-pattern of catching Exception just to silence the compiler.