Exception Handling

What Are Exceptions?

15 min Lesson 1 of 14

What Are Exceptions?

No program runs perfectly in every situation. A file might be missing, the user might type letters where a number was expected, or a network connection might drop mid-request. Java's exception handling mechanism gives you a structured, readable way to detect these problems, react to them, and keep your application alive — instead of simply crashing.

Errors vs Exceptions

Java splits abnormal conditions into two families, both descending from a common parent called Throwable:

Error — a serious problem that the JVM itself cannot recover from, such as running out of heap memory (OutOfMemoryError) or a corrupted class file (ClassFormatError). Your code should not try to catch these; they indicate the environment is broken.
Exception — a condition your code can reasonably anticipate and handle, such as a file not being found (FileNotFoundException), an illegal argument being passed (IllegalArgumentException), or dividing a number by zero (ArithmeticException).

Key idea: You write code to handle Exceptions. You almost never write code to handle Errors — if the JVM runs out of memory, no amount of clever code will save you; fix the environment instead.

What Happens When an Exception Occurs?

Consider this small program:

public class Demo {
    public static void main(String[] args) {
        int result = divide(10, 0);
        System.out.println("Result: " + result);
    }

    static int divide(int a, int b) {
        return a / b;   // dividing by zero throws ArithmeticException
    }
}

When Java evaluates a / b with b = 0, it cannot produce a meaningful integer. At that moment the JVM throws an ArithmeticException. If no code catches that exception, the JVM terminates the program and prints a stack trace — a report showing exactly where and how the problem occurred.

How Exceptions Unwind the Call Stack

Java keeps track of every method call on a data structure called the call stack. When you call main, which calls divide, the stack looks like this (top = currently executing):

divide  <-- currently executing
main

When divide throws an exception, Java looks for a catch block inside divide. Finding none, it pops divide off the stack and looks in the caller — main. Finding no catch there either, it pops main and reaches the JVM's default handler, which prints the stack trace and exits. This process of removing stack frames one by one while searching for a handler is called unwinding the call stack.

Why does unwinding matter? Any code that appears after the line that throws is skipped. In the example above, System.out.println("Result: " + result) never executes. Understanding this prevents a common beginner mistake: assuming later lines still run when an earlier line throws.

Reading a Stack Trace

Running the Demo class above produces output like this:

Exception in thread "main" java.lang.ArithmeticException: / by zero
	at Demo.divide(Demo.java:8)
	at Demo.main(Demo.java:3)

Break it down line by line:

Exception in thread "main" — which thread was running when the exception escaped. Most beginner programs have only one thread: main.
java.lang.ArithmeticException: / by zero — the fully-qualified exception class name, followed by a human-readable message that describes what went wrong.
at Demo.divide(Demo.java:8) — the innermost frame: the exception was thrown on line 8 of Demo.java, inside the method divide.
at Demo.main(Demo.java:3) — the caller: main was on line 3 when it called divide. Each subsequent frame is the method that called the one above it.

Stack traces are listed innermost first. When you see a long trace in a real project, always start at the very top — that is where the exception actually happened. The lines below show the path that led there.

Common pitfall — ignoring the top line. Beginners often scroll to the bottom of a stack trace. The bottom shows your main method, which is rarely the actual problem. The useful information — the exception type, message, and exact line — is at the top.

A Slightly Deeper Example

Here is a three-level call chain so you can see a longer trace:

public class StackDemo {

    public static void main(String[] args) {
        level1();
    }

    static void level1() {
        level2();
    }

    static void level2() {
        String text = null;
        System.out.println(text.length());  // NullPointerException here
    }
}

The stack trace will be:

Exception in thread "main" java.lang.NullPointerException:
    Cannot invoke "String.length()" because "text" is null
	at StackDemo.level2(StackDemo.java:13)
	at StackDemo.level1(StackDemo.java:8)
	at StackDemo.main(StackDemo.java:4)

Reading top-to-bottom: the crash happened in level2 at line 13. That method was called from level1 at line 8, which was called from main at line 4. Java 17+ even adds a helpful plain-English hint: "because 'text' is null" — making NullPointerExceptions far easier to diagnose than in older versions.

Summary

Exceptions are Java's way of signalling that something unexpected happened during execution. Errors are JVM-level problems you leave alone; Exceptions are application-level problems you handle. When an exception is thrown and not caught, Java unwinds the call stack frame by frame until it finds a handler or terminates. The stack trace it prints is your first diagnostic tool — always read it from the top. In the next lesson you will learn how to write try, catch, and finally blocks to intercept exceptions before they unwind all the way out.