Exception Handling in Java

Every program you write is a set of instructions running one after another in a predictable sequence. Your code opens a file, reads some data, does a calculation, stores a result. That sequence is your program's normal flow. But real programs live in a messy world where things go wrong. A file disappears. Someone passes a negative number where only positive numbers make sense. A network connection drops mid transfer. When any of these unexpected events hit your running program and break that normal flow, Java calls it an exception.

The word "exception" is deliberately chosen. It is an exceptional event, something outside the happy path, something that your program did not expect to encounter at that point. When one of these events occurs during execution, the Java runtime does something very specific. It creates an exception object. That object carries three critical pieces of information: the type of exception that occurred, a human readable message explaining what went wrong, and something called a stack trace. You will see all three of these every time your program crashes with an unhandled exception in the console output.

What Is a Stack Trace

A stack trace is a record of the execution path from the point where the exception occurred all the way back to where your program started. Imagine your main method calls methodOne, methodOne calls methodTwo, and methodTwo calls methodThree. If an exception fires inside methodThree, the stack trace shows you exactly that chain: methodThree at line 18, called by methodTwo at line 14, called by methodOne at line 10, called by main at line 6.

The runtime uses this stack trace to search for someone who can handle the exception. It starts at the method where the exception occurred and asks: can you handle this? If not, it moves up to the caller and asks again. It keeps climbing the call chain until it finds a handler. If it reaches the top of the chain without finding anyone willing to handle the exception, the program terminates abruptly and prints that entire stack trace to the console. That is the crash output you have probably already seen.

public class Main {
    public static void main(String[] args) {
        methodOne();
    }

    static void methodOne() {
        methodTwo();
    }

    static void methodTwo() {
        methodThree();
    }

    static void methodThree() {
        // This causes ArithmeticException: / by zero
        int result = 5 / 0;
    }
}

When you run this, the output shows the type (ArithmeticException), the message (/ by zero), and the full chain of calls from methodThree back to main. Nobody in the chain handled it, so the program dies.

The Exception Hierarchy

To understand exception handling deeply you need to understand the class hierarchy that Java uses. At the top of every Java class hierarchy sits Object. One of its subclasses is Throwable. Everything that can be thrown in Java must be a Throwable or a descendant of it.

Throwable has two direct children: Error and Exception. This is one of the most important distinctions in Java and it comes up in interviews constantly.

Error represents problems that are outside your control and outside your program's control entirely. These are JVM level problems. The two classic examples are OutOfMemoryError and StackOverflowError. When the JVM runs out of heap space to create new objects, it throws OutOfMemoryError. When your stack memory fills up, typically because of infinite recursion where a method keeps calling itself with no exit condition, you get StackOverflowError. These are not things your code caused in a way you can fix at runtime. You should not try to catch or handle errors. They represent a situation so dire that the JVM itself is telling you something is fundamentally broken.

// This triggers OutOfMemoryError if the array is huge enough
String[] massiveArray = new String[Integer.MAX_VALUE];

// This triggers StackOverflowError
public static void infiniteRecursion() {
    infiniteRecursion(); // No base case, calls itself forever
}

Exception is the branch you care about. These represent problems that are related to your code, and you have control over them. You can catch them, handle them gracefully, and let your program continue running. This is what exception handling is all about.

Checked vs Unchecked: The Two Flavors of Exception

Under Exception there are two categories: checked exceptions and unchecked exceptions. You will also hear them called compile time exceptions and runtime exceptions respectively. The names tell you exactly when the problem surfaces.

Unchecked exceptions (also called runtime exceptions) are problems that only show up when you actually run the program. The compiler does not force you to handle them. Your code compiles perfectly fine whether you handle them or not. But when execution hits the problematic line at runtime, the exception fires. All runtime exceptions extend RuntimeException, which itself extends Exception.

Checked exceptions (also called compile time exceptions) are problems that the compiler actively checks for. If your code can throw a checked exception and you have not handled it properly, the Java compiler refuses to compile your code. You will see a compile error. The compiler is forcing you to deal with it before your program can even run.

This is a crucial design choice in Java. With unchecked exceptions, the compiler trusts you to handle them if you want but does not demand it. With checked exceptions, the compiler says: this situation is serious enough that I will not let your code run unless you have a plan for it.

Is Error Checked or Unchecked?

This is a classic interview question. Errors are unchecked. They are categorized with runtime behavior because they happen while the program is running, not at compile time. The compiler never forces you to handle an OutOfMemoryError. Errors are in the unchecked category.

The Runtime Exceptions You Will See Every Day

These are the exceptions that extend RuntimeException. The compiler will never warn you about them, but you will encounter each of them in real development.

ClassCastException happens when you try to cast an object to a type that it is not. If you store an Integer in an Object reference and then try to cast it to a String, Java will throw ClassCastException at runtime because an Integer is not a String.

Object value = 42; // Integer stored in Object reference
// This compiles fine, but crashes at runtime
String text = (String) value; // ClassCastException: Integer cannot be cast to String

ArithmeticException happens when you perform an illegal arithmetic operation. The most common example is dividing an integer by zero.

int result = 5 / 0; // ArithmeticException: / by zero

ArrayIndexOutOfBoundsException happens when you try to access an index that does not exist in an array. An array of size 2 has valid indices 0 and 1. Accessing index 2 throws this exception.

int[] values = new int[2]; // Valid indices: 0 and 1
System.out.println(values[3]); // ArrayIndexOutOfBoundsException

StringIndexOutOfBoundsException is the String equivalent. The string "hello" has characters at indices 0 through 4. Calling charAt(5) throws this exception.

String word = "hello"; // Characters at indices 0,1,2,3,4
char ch = word.charAt(5); // StringIndexOutOfBoundsException

NullPointerException is perhaps the most famous Java exception. It happens when you try to call a method or access a field on a reference that is null. You cannot call .charAt() on nothing.

String value = null;
char ch = value.charAt(0); // NullPointerException: value is null

NumberFormatException happens when you try to parse a string as a number but the string is not a valid number. Parsing "53" works fine. Parsing "ABC" does not.

int number = Integer.parseInt("53");  // Works, gives 53
int broken = Integer.parseInt("ABC"); // NumberFormatException

Every single one of these compiles without complaint. The compiler does not warn you. You only discover the problem at runtime, which is why they are called runtime exceptions.

The Checked Exceptions You Must Handle

These exceptions live directly under Exception, not under RuntimeException. The compiler treats them specially and will refuse to compile your code if they are not handled. Common examples include ClassNotFoundException, InterruptedException, IOException, FileNotFoundException, EOFException, and SQLException. You will encounter most of these when working with files, databases, and network connections.

The reason these exist is that the situations they represent are predictable and recoverable. A file not being found is something you can plan for. A database connection failing is something you can handle. Java's designers made these checked because ignoring them silently would lead to serious bugs in production software.

The Five Keywords of Exception Handling

Java gives you five keywords to work with exceptions: try, catch, finally, throw, and throws. Every piece of exception handling code you write uses some combination of these five.

try and catch: The Core Pattern

The try block is where you put code that might throw an exception. The catch block is where you put the code that runs when a specific exception type is thrown from inside the try block.

public static void methodOne() throws ClassNotFoundException {
    throw new ClassNotFoundException("Resource not found");
}

public static void main(String[] args) {
    try {
        // This code might throw ClassNotFoundException
        methodOne();
    } catch (ClassNotFoundException e) {
        // Handle it here: log it, show a user message, take corrective action
        System.out.println("Caught: " + e.getMessage());
    }
}

When methodOne throws the exception, execution immediately jumps out of the try block and into the matching catch block. The code after the throw inside the try block is skipped. Inside the catch block, you have full access to the exception object and can do whatever makes sense: log it, display a friendly message, retry the operation, or anything else.

throws: Delegating Responsibility

throws is different from throw. It is a declaration on a method signature that tells the world: this method might produce this kind of exception, and I am not going to handle it here. Whoever calls me must handle it.

// methodOne declares that it might throw ClassNotFoundException
// It does not handle it; it passes the responsibility to whoever calls it
public static void methodOne() throws ClassNotFoundException {
    throw new ClassNotFoundException("Class not found");
}

throws only appears after a method's parameter list, separated by a comma if there are multiple exception types. It is a contract with the caller. When you use throws, the caller now has the same obligation: they must either handle it with try and catch, or they must also declare throws and pass the responsibility further up.

The key difference: throws is a declaration that says "this might happen." throw is the actual action of making it happen.

throw: Creating and Rethrowing Exceptions

You use the throw keyword in two situations. The first is to throw a new exception when something goes wrong in your code:

public static void greetUser(String name) {
    if (name.equals("dummy")) {
        throw new IllegalArgumentException("Invalid name provided");
    }
    System.out.println("Hello, " + name);
}

The second use is rethrowing an exception that you already caught:

public static void main(String[] args) {
    try {
        methodOne();
    } catch (ClassNotFoundException e) {
        // Do some logging or specific action first
        System.out.println("Logging: exception caught at main level");
        // Now rethrow it, forcing the JVM to terminate since nobody above handles it
        throw e;
    }
}

You might wonder: if I am going to rethrow it anyway, why catch it at all? The answer is that rethrowing is useful when you need to do something specific at this layer, like adding a log message with context that only this method has, before letting the exception continue up the stack. You catch it, do your layer specific work, and then rethrow so the caller can also handle it or let it terminate.

Multiple catch Blocks: Handling Different Exception Types

A single try block can have multiple catch blocks, each handling a different exception type:

public static void methodOne() throws ClassNotFoundException, InterruptedException {
    // This method might throw either exception
}

public static void main(String[] args) {
    try {
        methodOne();
    } catch (ClassNotFoundException e) {
        System.out.println("Class not found: " + e.getMessage());
    } catch (InterruptedException e) {
        System.out.println("Thread interrupted: " + e.getMessage());
    }
}

There is a critical rule about the order of catch blocks: you must always put the more specific exception type before the more general one. Exception is the parent of almost all exceptions, which means a catch (Exception e) block can catch anything. If you put it first, every exception will match it and your specific catch blocks below will never execute. The compiler actually catches this mistake and marks the unreachable catch blocks with an error.

// WRONG: catch (Exception e) first swallows everything
try {
    methodOne();
} catch (Exception e) {           // Too general, catches everything
    System.out.println("Generic");
} catch (ClassNotFoundException e) { // This line will never be reached
    System.out.println("Specific");   // Compiler error: already caught above
}

// RIGHT: specific before general
try {
    methodOne();
} catch (ClassNotFoundException e) { // More specific, checked first
    System.out.println("Specific");
} catch (Exception e) {              // General fallback
    System.out.println("Generic fallback");
}

Multi catch: One catch Block for Multiple Types

If two exception types require identical handling code, you do not need two separate catch blocks. Java allows you to catch multiple exception types in a single catch block using the pipe symbol:

try {
    methodOne(); // Can throw ClassNotFoundException or InterruptedException
} catch (ClassNotFoundException | InterruptedException e) {
    // Same handling for both
    System.out.println("Either class not found or interrupted: " + e.getMessage());
} catch (Exception e) {
    // Catch any other exception
    System.out.println("Something else went wrong");
}

This keeps your code clean when the handling logic is the same regardless of which specific exception fired.

finally: The Block That Always Runs

The finally block runs after the try block and after any catch block, no matter what happens. It runs whether the try block succeeded, whether an exception was thrown and caught, and even if you use return inside the try block. The control always passes through finally before actually leaving the method.

public static void methodOne() {
    try {
        System.out.println("Inside try block");
        return; // Even this return does not skip finally
    } finally {
        System.out.println("Inside finally"); // This still prints
    }
}

Output:

Inside try block
Inside finally

You can only have one finally block per try statement. You can have many catch blocks, but only one finally.

The primary use of finally is cleanup. In Java you often open resources like file streams, database connections, or network sockets. If you open a stream inside a try block and an exception fires before you close it, the stream stays open and leaks resources. The finally block guarantees cleanup happens regardless:

public static void readFile() throws Exception {
    SomeResource resource = openResource();
    try {
        // Use the resource
        resource.read();
    } catch (Exception e) {
        System.out.println("Error while reading: " + e.getMessage());
    } finally {
        // This runs whether reading succeeded or failed
        resource.close(); // Always clean up
        System.out.println("Resource closed");
    }
}

Another common use is logging. Since finally always executes, you can place a log statement there and be certain it runs every time the method is exited, regardless of the exit path.

There are only two situations where finally does not run. First, if the JVM itself crashes: if you get OutOfMemoryError or StackOverflowError or the process is forcefully killed by the operating system, the JVM might not get a chance to execute finally. Second, if you call System.exit() inside the try block, the JVM shuts down and finally is skipped. Outside of these edge cases, finally always runs. That is a guarantee you can rely on.

You can also use try with finally but without any catch block at all. This is valid when you want to ensure cleanup but you still want any exception to propagate up to the caller:

// try-finally without catch: cleans up but lets exception propagate
public static void processData() throws ClassNotFoundException {
    try {
        methodOne(); // Might throw ClassNotFoundException
    } finally {
        System.out.println("Cleanup always happens here");
        // Exception still propagates to whoever called processData
    }
}

Custom Exception Classes

Java's built in exceptions cover a lot of ground, but sometimes you need an exception that carries meaning specific to your domain. You can create your own exception classes by extending Exception or any of its subclasses.

If you extend Exception directly, your custom exception behaves like a checked exception and the compiler will require callers to handle it. If you extend RuntimeException, it behaves like an unchecked exception and callers can choose whether to handle it.

// Custom checked exception: extends Exception
public class InsufficientFundsException extends Exception {

    public InsufficientFundsException(String message) {
        super(message); // Pass the message to the parent Exception class
    }
}

// Using the custom exception
public class BankAccount {

    private double balance;

    public BankAccount(double initialBalance) {
        this.balance = initialBalance;
    }

    public void withdraw(double amount) throws InsufficientFundsException {
        if (amount > balance) {
            throw new InsufficientFundsException(
                "Attempted to withdraw " + amount + " but balance is only " + balance
            );
        }
        balance -= amount;
    }
}

public class Main {
    public static void main(String[] args) {
        BankAccount account = new BankAccount(100.0);
        try {
            account.withdraw(200.0);
        } catch (InsufficientFundsException e) {
            System.out.println("Transaction failed: " + e.getMessage());
        }
    }
}

Because InsufficientFundsException extends Exception, it behaves exactly like any other checked exception. The compiler requires callers of withdraw to either handle it with try and catch or declare that they also throw it. You place it in the exception hierarchy where it makes sense. If you want a domain specific exception that is more specific than a general Exception but not a runtime exception, extending Exception is the right choice.

You can also extend a specific built in exception if your custom exception is a specialized version of something that already exists:

// Custom exception that is a more specific kind of IOException
public class DatabaseConnectionException extends IOException {
    public DatabaseConnectionException(String message) {
        super(message);
    }
}

Why Exception Handling Makes Your Code Better

Now that you know how exception handling works, you should understand why it exists. The clearest way to see the benefit is to compare the same problem solved with and without exceptions.

Suppose you have a method that takes a class number (1 through 12), looks up how many students are in that class, creates an array for them, and fills in the first slot. There are several things that could go wrong: the class number might be invalid, the capacity might be zero, the array might be null. Without exception handling, you have to guard every step with an if statement and return error codes:

// Without exception handling: messy, hard to read
public static int processClass(int classNumber) {
    if (classNumber <= 0 || classNumber > 12) {
        return -1; // Error code for invalid class number
    }

    int numberOfStudents = getStudentCapacity(classNumber);
    if (numberOfStudents == 0) {
        return -2; // Error code for empty class
    }

    String[] names = new String[numberOfStudents];
    if (names == null || names.length == 0) {
        return -3; // Error code for array problem
    }

    names[0] = "New Student";
    return 0; // Success
}

Now the caller receives an integer and has to check it: if it is minus 1 do this, if it is minus 2 do that. And if this method is called by another method which is called by another method, that error code has to be passed all the way up the chain. Every method in the chain has to check the return value and cascade it upward.

With exception handling, the same logic becomes far cleaner:

// With exception handling: clean, readable, focused
public static void processClass(int classNumber) throws IllegalArgumentException, IOException {
    try {
        // Your actual business logic, uncluttered by error checks
        int numberOfStudents = getStudentCapacity(classNumber);
        String[] names = new String[numberOfStudents];
        names[0] = "New Student";
    } catch (ArrayIndexOutOfBoundsException e) {
        System.out.println("Array problem: " + e.getMessage());
    } catch (Exception e) {
        System.out.println("Unexpected error: " + e.getMessage());
    }
}

The business logic is in the try block. The error handling is in the catch blocks. They are separated. When you read the try block you see what the method is supposed to do, not a maze of validation checks. When something goes wrong, the exception object carries rich information: the type, the message, the exact line number, the full stack trace. You do not have to invent your own error code system.

Instead of cascading an integer error code up through every layer of the call stack, you can let the exception propagate automatically using throws. The exception object travels up the call chain on its own. Any layer that wants to handle it can. Any layer that does not can declare throws and stay out of it.

Exception handling also gives you a chance to recover. When you catch an exception, you can sometimes correct the situation and continue. If an index is out of bounds, maybe you can resize. If a file is not found, maybe you can create it or use a default. You are not forced to terminate.

From a debugging standpoint, the stack trace is invaluable. Without exception handling, if you return error code minus 10 from deep in a call chain, you know something went wrong but you have no idea where or why. With an exception, you have the exact file, the exact line, the exact method chain, and a message. Debugging becomes dramatically faster.

Exceptions also improve security. When a failure occurs, you control exactly what information appears in logs. You can catch an exception, log a safe sanitized message, and avoid leaking sensitive data like passwords or customer personal information into log files.

The Cost of Exception Handling

Exception handling is not free. There is one disadvantage you should understand. When an exception propagates up a long call chain without being caught, the JVM has to walk that entire chain checking at each level. If your call stack is 100 methods deep and none of them handle the exception, that is 100 checks before the program terminates. That is overhead.

This cost is usually acceptable because exceptions represent genuinely exceptional situations, not normal code flow. But it means you should not use exceptions as a substitute for simple conditional checks that you could handle with an if statement.

Consider this:

// Using exception handling for something a simple if would handle
public static int divide(int a, int b) {
    try {
        return a / b;
    } catch (ArithmeticException e) {
        return -1;
    }
}

// Simpler and cheaper: just check the condition
public static int divide(int a, int b) {
    if (b == 0) {
        return -1;
    }
    return a / b;
}

Both work. But the second version has no overhead. There is no exception object created, no stack unwinding. If you can handle a predictable condition with a simple check, do that. Reserve exception handling for situations that are genuinely exceptional, not just conditions you can test for with an if.

Interview Questions and Common Pitfalls

What is the difference between Error and Exception?

Both extend Throwable. Error represents JVM level problems like running out of memory or overflowing the stack. These are not in your code's control and you should not handle them. Exception represents problems in your code that you can handle and recover from. Exceptions have two subtypes: checked (compile time) and unchecked (runtime).

What is the difference between checked and unchecked exceptions?

Checked exceptions (compile time exceptions) must be handled explicitly. The compiler refuses to compile your code if you have a checked exception that is neither caught nor declared with throws. Unchecked exceptions (runtime exceptions) do not require explicit handling. The compiler lets them through. They surface only when you actually run the program.

What is the difference between throw and throws?

throw is an action: you use it inside a method to actually throw an exception object. throws is a declaration: you use it on a method signature to declare that this method might throw a certain exception. throw makes something happen. throws is a warning to callers.

Does finally always execute?

Almost always. The only situations where it does not are: JVM crash (OutOfMemoryError, StackOverflowError, process killed), calling System.exit(), or infinite loops in the try block that prevent reaching the finally. In all other cases, including when you return from inside the try block, finally always executes.

Can you have multiple catch blocks?

Yes, and you should put the most specific exception type first. If you put Exception first, it catches everything and your specific catch blocks below it are unreachable. The compiler will flag this as an error.

Can you catch multiple exceptions in one catch block?

Yes, using the pipe symbol: catch (ClassNotFoundException | InterruptedException e). This is useful when the handling code is identical for both types.

What happens if you throw inside a catch block?

The exception from the catch block propagates up. If you have a finally block, it runs first. Then the exception continues up the call stack looking for a handler.

Can you use throws without a catch block?

Yes. A method can declare throws SomeException and simply let any exception propagate to the caller without ever catching anything. The caller must then handle it or also declare throws.

What is rethrowing an exception?

Catching an exception and then throwing it again using throw e inside the catch block. You do this when you need to perform some action at the current layer, like logging or adding context, before letting the exception continue up the call stack to be handled by a caller that has more context to deal with it.

What is a custom exception?

A class that you write yourself that extends Exception (making it a checked exception) or RuntimeException (making it unchecked). Custom exceptions let you create domain specific exception types that carry meaningful names and messages for your business logic.

When should you avoid exception handling?

When a simple conditional check can handle the situation. If you can write if (b == 0) return -1 instead of wrapping a division in try and catch, the simple check is cheaper, clearer, and equally correct. Exception handling has overhead and should be reserved for situations that are genuinely unexpected rather than conditions you could have checked for.

Putting It All Together

Exception handling transforms your programs from fragile sequences that die on the first unexpected input into robust systems that can respond thoughtfully to problems. Instead of crashing and printing a raw stack trace to your users, you catch specific exception types, display meaningful messages, log safely, clean up resources in finally, and where appropriate continue executing.

The hierarchy gives you precision. You can write catch blocks for very specific exceptions when you know exactly what went wrong and have a specific response, and fall back to a general Exception catch for anything you did not anticipate. The five keywords give you complete control over where exceptions originate, where they are declared, where they are caught, and what runs regardless of outcome.

Custom exceptions let you make your exception hierarchy part of your design. An InsufficientFundsException communicates more intent than a generic Exception with a message string. It lets callers make decisions based on the exception type itself, not just the message.

Start by practicing with the runtime exceptions you already know, because you will encounter them in every project. Then practice the checked exception pattern: write a method that throws a checked exception, use throws to propagate it, and then handle it with try and catch at the appropriate layer. Once that feels natural, write a custom exception class, throw it from domain logic, and catch it in your main code. That progression will make every exception scenario you encounter on a real project feel familiar.