Java Exception Handling Exercises: 20 Coding Problems with Solutions

This collection of 20 Java exception handling exercises starts with a basic try-catch block and builds all the way up to custom exceptions, chaining, and the subtleties of try-with-resources.

• Early exercises cover catching basic exceptions, ordering multiple catch blocks correctly, and the guarantees of a finally block.
• The middle set introduces checked versus unchecked exceptions, the throws keyword, writing your own custom checked and unchecked exception classes, re-throwing, and the Java 7+ multi-catch syntax.
• The final exercises cover try-with-resources, exception chaining to preserve a root cause, suppressed exceptions during cleanup, a thread’s uncaught exception handler, and the distinction between Exception and Error.

Each exercise includes a Problem Statement, Purpose, Hint, and a Solution with Explanation that clarifies exactly which exception is thrown and why.

Exercise 1: Divide-by-Zero Exception

Problem Statement: Write a program that accepts two integers from the user and divides the first by the second. Use a try-catch block to handle ArithmeticException if the user enters 0 as the denominator, displaying a friendly error message instead of crashing.

Purpose: This exercise introduces the basic try-catch structure, showing how a program can recover from a runtime error instead of terminating abruptly.

Given Input: numerator = 10, denominator = 0

Expected Output: Error: Cannot divide by zero. Please try a non-zero denominator.

import java.util.Scanner;

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        System.out.print("Enter numerator: ");
        int numerator = scanner.nextInt();
        System.out.print("Enter denominator: ");
        int denominator = scanner.nextInt();

        try {
            int result = numerator / denominator;
            System.out.println("Result: " + result);
        } catch (ArithmeticException e) {
            System.out.println("Error: Cannot divide by zero. Please try a non-zero denominator.");
        }
    }
}Code language: Java (java)

Exercise 2: Array Bounds Guard

Problem Statement: Create an integer array of size 5. Write a loop that attempts to access and print elements up to index 7. Catch the ArrayIndexOutOfBoundsException and print a message showing exactly which out-of-bounds index caused the failure.

Purpose: This exercise shows how a try-catch block can live inside a loop, letting the loop continue running instead of stopping the entire program the moment one iteration fails.

Given Input: int[] numbers = {10, 20, 30, 40, 50};

Expected Output:

Element at index 0: 10
Element at index 1: 20
Element at index 2: 30
Element at index 3: 40
Element at index 4: 50
Error: Index 5 is out of bounds for this array.
Error: Index 6 is out of bounds for this array.
Error: Index 7 is out of bounds for this array.

public class Main {
    public static void main(String[] args) {
        int[] numbers = {10, 20, 30, 40, 50};

        for (int i = 0; i <= 7; i++) {
            try {
                System.out.println("Element at index " + i + ": " + numbers[i]);
            } catch (ArrayIndexOutOfBoundsException e) {
                System.out.println("Error: Index " + i + " is out of bounds for this array.");
            }
        }
    }
}Code language: Java (java)

Exercise 3: NumberFormatException Retry Loop

Problem Statement: Prompt the user to enter their age as a string. Attempt to parse it into an integer using Integer.parseInt(). Catch NumberFormatException and continuously prompt the user until they enter a valid numeric value.

Purpose: This exercise combines exception handling with a loop to build a validation retry pattern, a technique used constantly when reading and sanitizing user input.

Given Input: User enters "abc", then "25"

Expected Output:

Invalid input. Please enter a numeric value.
Your age is: 25

import java.util.Scanner;

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        int age = 0;
        boolean valid = false;

        while (!valid) {
            System.out.print("Enter your age: ");
            String input = scanner.nextLine();
            try {
                age = Integer.parseInt(input);
                valid = true;
            } catch (NumberFormatException e) {
                System.out.println("Invalid input. Please enter a numeric value.");
            }
        }
        System.out.println("Your age is: " + age);
    }
}Code language: Java (java)

Exercise 4: Catching NullPointerException

Problem Statement: Create a method String toUpperCase(String str). Inside, purposely do not check for null natively; instead, wrap the .toUpperCase() call in a try-catch block. Catch NullPointerException, print a warning, and return a default string like "EMPTY".

Purpose: This exercise shows how NullPointerException, one of the most common runtime errors in Java, can be caught like any other exception, even though an explicit if (str == null) check is usually the better style in production code.

Given Input: toUpperCase("hello"); toUpperCase(null);

Expected Output:

HELLO
Warning: Received a null string.
EMPTY

public class Main {
    public static String toUpperCase(String str) {
        try {
            return str.toUpperCase();
        } catch (NullPointerException e) {
            System.out.println("Warning: Received a null string.");
            return "EMPTY";
        }
    }

    public static void main(String[] args) {
        System.out.println(toUpperCase("hello"));
        System.out.println(toUpperCase(null));
    }
}Code language: Java (java)

Exercise 5: The Hierarchy Trap (Multiple Catch Blocks)

Problem Statement: Write a code snippet that intentionally triggers both an ArrayIndexOutOfBoundsException and an ArithmeticException. Write multiple catch blocks. Bonus challenge: Intentional order violation. Try catching Exception before ArithmeticException and observe the compiler error. Fix it by ordering them from specific to general.

Purpose: This exercise demonstrates how multiple catch blocks are evaluated top to bottom, and why the Java compiler enforces that more specific exception types must be caught before more general ones.

Given Input: int[] numbers = {1, 2, 3}; accessed at index 5, then 10 / 0

Expected Output:

Caught: Array index out of bounds.
Caught: Arithmetic error.

public class Main {
    public static void main(String[] args) {
        int[] numbers = {1, 2, 3};

        try {
            System.out.println(numbers[5]);
        } catch (ArrayIndexOutOfBoundsException e) {
            System.out.println("Caught: Array index out of bounds.");
        } catch (ArithmeticException e) {
            System.out.println("Caught: Arithmetic error.");
        } catch (Exception e) {
            System.out.println("Caught: Some other exception.");
        }

        try {
            int result = 10 / 0;
            System.out.println(result);
        } catch (ArrayIndexOutOfBoundsException e) {
            System.out.println("Caught: Array index out of bounds.");
        } catch (ArithmeticException e) {
            System.out.println("Caught: Arithmetic error.");
        } catch (Exception e) {
            System.out.println("Caught: Some other exception.");
        }
    }
}Code language: Java (java)

Exercise 6: finally Block Guarantee

Problem Statement: Create a method that opens a try block, prints a message, and immediately executes a return statement. Add a finally block that prints "I am inevitable". Verify whether the finally block executes even though the method returned early.

Purpose: This exercise demonstrates a key guarantee of the try-finally structure: the finally block always runs before control actually leaves the method, even when a return statement fires inside the try block.

Given Input: int result = demoFinally();

Expected Output:

Inside try block
I am inevitable
Returned value: 1

public class Main {
    public static int demoFinally() {
        try {
            System.out.println("Inside try block");
            return 1;
        } finally {
            System.out.println("I am inevitable");
        }
    }

    public static void main(String[] args) {
        int result = demoFinally();
        System.out.println("Returned value: " + result);
    }
}Code language: Java (java)

Exercise 7: Nested Try-Catch Blocks

Problem Statement: Write a program with a nested try-catch structure. The outer block should handle a NumberFormatException, while the inner block handles an ArithmeticException. Trigger the inner exception, catch it, and then intentionally trigger the outer exception from inside the inner catch block.

Purpose: This exercise shows that a catch block is ordinary code that can itself throw a new exception, and that an outer try-catch can handle a failure that originates from inside an inner catch block.

Given Input: none (the exceptions are triggered directly in code)

Expected Output:

Outer try started
Inner try started
Inner catch: Arithmetic exception caught.
Outer catch: Number format exception caught.

public class Main {
    public static void main(String[] args) {
        try {
            System.out.println("Outer try started");

            try {
                System.out.println("Inner try started");
                int result = 10 / 0;
                System.out.println(result);
            } catch (ArithmeticException e) {
                System.out.println("Inner catch: Arithmetic exception caught.");
                int value = Integer.parseInt("abc");
                System.out.println(value);
            }

        } catch (NumberFormatException e) {
            System.out.println("Outer catch: Number format exception caught.");
        }
    }
}Code language: Java (java)

Exercise 8: Age Validator with Explicit throw

Problem Statement: Write a method validateAge(int age) that throws an IllegalArgumentException with the message "Access Denied: Under 18" if the age is less than 18. Call this method in main and handle the exception.

Purpose: This exercise practices manually throwing an exception with throw, rather than relying on the JVM to raise one, which is how custom validation rules are typically enforced in Java.

Given Input: validateAge(15);

Expected Output: Error: Access Denied: Under 18

public class Main {
    public static void validateAge(int age) {
        if (age < 18) {
            throw new IllegalArgumentException("Access Denied: Under 18");
        }
        System.out.println("Access Granted: Age " + age + " is valid.");
    }

    public static void main(String[] args) {
        try {
            validateAge(15);
        } catch (IllegalArgumentException e) {
            System.out.println("Error: " + e.getMessage());
        }
    }
}Code language: Java (java)

Exercise 9: throws Keyword Declaration

Problem Statement: Create a method readFile(String path) that attempts to use a FileReader. Because FileReader throws a checked FileNotFoundException, do not use a try-catch inside the method. Instead, use the throws keyword in the method signature to pass the responsibility to the caller.

Purpose: This exercise introduces checked exceptions and the throws keyword, showing that a method is allowed to declare a checked exception instead of handling it, shifting the obligation to whoever calls it.

Given Input: readFile("nonexistent.txt");

Expected Output: Error: File not found or unreadable.

import java.io.FileReader;
import java.io.IOException;

public class Main {
    public static void readFile(String path) throws IOException {
        FileReader reader = new FileReader(path);
        reader.close();
    }

    public static void main(String[] args) {
        try {
            readFile("nonexistent.txt");
        } catch (IOException e) {
            System.out.println("Error: File not found or unreadable.");
        }
    }
}Code language: Java (java)

Exercise 10: Checked vs Unchecked Exceptions

Problem Statement: Write a class with two methods: methodA() which throws a checked exception (IOException), and methodB() which throws an unchecked exception (NullPointerException). Write a main method that calls both, demonstrating why the compiler forces you to handle or declare methodA but lets methodB slide.

Purpose: This exercise closes out the series by directly contrasting checked and unchecked exceptions side by side, making clear which category the compiler actively enforces and which it leaves entirely to the programmer’s discipline.

Given Input: methodA(); methodB();

Expected Output:

Caught checked exception: Simulated I/O failure
Caught unchecked exception: Simulated null reference

import java.io.IOException;

public class Main {
    public static void methodA() throws IOException {
        throw new IOException("Simulated I/O failure");
    }

    public static void methodB() {
        throw new NullPointerException("Simulated null reference");
    }

    public static void main(String[] args) {
        try {
            methodA();
        } catch (IOException e) {
            System.out.println("Caught checked exception: " + e.getMessage());
        }

        try {
            methodB();
        } catch (NullPointerException e) {
            System.out.println("Caught unchecked exception: " + e.getMessage());
        }
    }
}Code language: Java (java)

Exercise 11: Custom Checked Exception: InsufficientFundsException

Problem Statement: Simulate a simple banking system. Create a custom checked exception named InsufficientFundsException (extending Exception). Write a BankAccount class with a withdraw(double amount) method that throws this exception if the withdrawal amount exceeds the balance.

Purpose: This exercise introduces creating your own checked exception class, showing how domain-specific errors like a failed withdrawal can be modeled as first-class exception types instead of generic ones.

Given Input: BankAccount account = new BankAccount(500.0); account.withdraw(700.0);

Expected Output: Error: Insufficient funds: balance is 500.0, requested 700.0

class InsufficientFundsException extends Exception {
    public InsufficientFundsException(String message) {
        super(message);
    }
}

class BankAccount {
    private double balance;

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

    public void withdraw(double amount) throws InsufficientFundsException {
        if (amount > balance) {
            throw new InsufficientFundsException("Insufficient funds: balance is " + balance + ", requested " + amount);
        }
        balance -= amount;
        System.out.println("Withdrawal successful. Remaining balance: " + balance);
    }
}

public class Main {
    public static void main(String[] args) {
        BankAccount account = new BankAccount(500.0);
        try {
            account.withdraw(700.0);
        } catch (InsufficientFundsException e) {
            System.out.println("Error: " + e.getMessage());
        }
    }
}Code language: Java (java)

Exercise 12: Custom Unchecked Exception: WeakPasswordException

Problem Statement: Create a custom unchecked exception named WeakPasswordException (extending RuntimeException). Write a registration utility that checks if a user’s password is at least 8 characters long and contains a number. Throw the exception if it fails the criteria.

Purpose: This exercise contrasts with the previous one by creating an unchecked custom exception, appropriate for validation failures that are considered programming or input errors rather than recoverable conditions the caller must be forced to handle.

Given Input: RegistrationUtil.validatePassword("abc123");

Expected Output: Registration failed: Password must be at least 8 characters long and contain a number.

class WeakPasswordException extends RuntimeException {
    public WeakPasswordException(String message) {
        super(message);
    }
}

class RegistrationUtil {
    public static void validatePassword(String password) {
        boolean hasDigit = password.matches(".*\\d.*");
        if (password.length() < 8 || !hasDigit) {
            throw new WeakPasswordException("Password must be at least 8 characters long and contain a number.");
        }
        System.out.println("Password accepted.");
    }
}

public class Main {
    public static void main(String[] args) {
        try {
            RegistrationUtil.validatePassword("abc123");
        } catch (WeakPasswordException e) {
            System.out.println("Registration failed: " + e.getMessage());
        }
    }
}Code language: Java (java)

Exercise 13: Re-throwing Exceptions

Problem Statement: Write a method that catches a SQLException (you can mock this or use any checked exception). Log the message locally by printing "Log: Exception captured", and then use the throw keyword to re-throw that exact same exception object up the call stack.

Purpose: This exercise shows that a catch block does not have to fully resolve an exception. It can perform local work, like logging, and still forward the original exception object to the caller for further handling.

Given Input: queryDatabase();

Expected Output:

Log: Exception captured
Main caught: Connection timed out

import java.sql.SQLException;

public class Main {
    public static void queryDatabase() throws SQLException {
        try {
            throw new SQLException("Connection timed out");
        } catch (SQLException e) {
            System.out.println("Log: Exception captured");
            throw e;
        }
    }

    public static void main(String[] args) {
        try {
            queryDatabase();
        } catch (SQLException e) {
            System.out.println("Main caught: " + e.getMessage());
        }
    }
}Code language: Java (java)

Exercise 14: The Modern Multi-Catch

Problem Statement: Write a program that can potentially throw a ParseException or an IOException. Instead of writing two separate catch blocks, use the Java 7+ multi-catch syntax (catch (ParseException | IOException e)) to handle both in a single block using a bitwise OR | operator.

Purpose: This exercise practices the multi-catch syntax, which reduces duplicated handling code when several unrelated exception types should be treated the same way.

Given Input: processInput("not-a-date", false);

Expected Output: Caught: ParseException - Unparseable date: "not-a-date"

import java.io.IOException;
import java.text.ParseException;
import java.text.SimpleDateFormat;

public class Main {
    public static void processInput(String dateStr, boolean simulateIOError) throws ParseException, IOException {
        if (simulateIOError) {
            throw new IOException("Simulated I/O failure");
        }
        SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd");
        format.parse(dateStr);
        System.out.println("Parsed successfully: " + dateStr);
    }

    public static void main(String[] args) {
        try {
            processInput("not-a-date", false);
        } catch (ParseException | IOException e) {
            System.out.println("Caught: " + e.getClass().getSimpleName() + " - " + e.getMessage());
        }
    }
}Code language: Java (java)

Exercise 15: Modern Cleanup (Try-With-Resources)

Problem Statement: Create a custom resource class named MockDatabaseConnection that implements the AutoCloseable interface. Override the close() method to print "Connection closed safely". Write a main method that uses try-with-resources to open this connection and witness it auto-closing without an explicit finally block.

Purpose: This exercise introduces try-with-resources, which automatically calls close() on any resource declared in its parentheses once the block finishes, removing the need for a manual finally block.

Given Input: none (the resource is opened and closed automatically)

Expected Output:

Connection opened
Executing: SELECT * FROM users
Connection closed safely

class MockDatabaseConnection implements AutoCloseable {
    public MockDatabaseConnection() {
        System.out.println("Connection opened");
    }

    public void query(String sql) {
        System.out.println("Executing: " + sql);
    }

    @Override
    public void close() {
        System.out.println("Connection closed safely");
    }
}

public class Main {
    public static void main(String[] args) {
        try (MockDatabaseConnection connection = new MockDatabaseConnection()) {
            connection.query("SELECT * FROM users");
        }
    }
}Code language: Java (java)

Exercise 16: Overriding Methods with Checked Exceptions

Problem Statement: Create a parent class Parent with a method void processData() throws IOException. Create a child class Child that overrides processData().

• Test what happens if the child tries to throw a broader exception like Exception.
• Test what happens if the child throws a more specific one like FileNotFoundException.
• Test what happens if the child throws an unchecked exception.

Purpose: This exercise explores how method overriding interacts with checked exceptions, a rule that exists so code calling through a Parent reference can never be surprised by a checked exception it did not already expect.

Given Input: Parent obj = new Child(); obj.processData();

Expected Output: Child processing data with a narrower exception

import java.io.FileNotFoundException;
import java.io.IOException;

class Parent {
    void processData() throws IOException {
        System.out.println("Parent processing data");
    }
}

class Child extends Parent {
    @Override
    void processData() throws FileNotFoundException {
        System.out.println("Child processing data with a narrower exception");
    }

    // Would NOT compile: declaring a broader checked exception than the parent.
    // @Override
    // void processData() throws Exception { }

    // Compiles fine: unchecked exceptions are never restricted by overriding rules.
    // @Override
    // void processData() { throw new RuntimeException("Unchecked is always allowed"); }
}

public class Main {
    public static void main(String[] args) {
        Parent obj = new Child();
        try {
            obj.processData();
        } catch (IOException e) {
            System.out.println("Caught: " + e.getMessage());
        }
    }
}Code language: Java (java)

Exercise 17: Exception Chaining

Problem Statement: Write a database adapter method. Catch a low-level SQLException (or a simulated IOException). Instead of losing the stack trace, wrap it inside a higher-level business exception like DataAccessException by passing the original exception into the new exception’s constructor (throw new DataAccessException("Fetch failed", e);).

Purpose: This exercise practices exception chaining, which lets a higher-level, more meaningful exception replace a low-level one at the API boundary while still preserving the original cause for debugging.

Given Input: adapter.fetchRecord();

Expected Output:

Error: Fetch failed
Caused by: Connection reset by peer

import java.io.IOException;

class DataAccessException extends RuntimeException {
    public DataAccessException(String message, Throwable cause) {
        super(message, cause);
    }
}

class DatabaseAdapter {
    public void fetchRecord() {
        try {
            throw new IOException("Connection reset by peer");
        } catch (IOException e) {
            throw new DataAccessException("Fetch failed", e);
        }
    }
}

public class Main {
    public static void main(String[] args) {
        DatabaseAdapter adapter = new DatabaseAdapter();
        try {
            adapter.fetchRecord();
        } catch (DataAccessException e) {
            System.out.println("Error: " + e.getMessage());
            System.out.println("Caused by: " + e.getCause().getMessage());
        }
    }
}Code language: Java (java)

Exercise 18: Suppressed Exceptions

Problem Statement: Using try-with-resources, create a scenario where the code inside the try block throws an exception, and the close() method of the resource also throws an exception. Catch the primary exception in main and use e.getSuppressed() to extract and print the hidden exception thrown during cleanup.

Purpose: This exercise reveals a subtle behavior of try-with-resources: when both the body and close() throw, only the body’s exception propagates as the primary one, while the close() exception is attached to it as a suppressed exception rather than lost.

Given Input: try (RiskyResource resource = new RiskyResource()) { resource.use(); }

Expected Output:

Primary exception: Failure during use
Suppressed exception: Failure during close

class RiskyResource implements AutoCloseable {
    public void use() {
        throw new RuntimeException("Failure during use");
    }

    @Override
    public void close() {
        throw new RuntimeException("Failure during close");
    }
}

public class Main {
    public static void main(String[] args) {
        try (RiskyResource resource = new RiskyResource()) {
            resource.use();
        } catch (RuntimeException e) {
            System.out.println("Primary exception: " + e.getMessage());
            for (Throwable suppressed : e.getSuppressed()) {
                System.out.println("Suppressed exception: " + suppressed.getMessage());
            }
        }
    }
}Code language: Java (java)

Exercise 19: Uncaught Exception Handler

Problem Statement: Write a program that starts a separate background thread. Intentionally crash that thread with a NullPointerException. Before running it, implement and register a Thread.UncaughtExceptionHandler globally or for that specific thread to elegantly log the crash instead of letting it dump to System.err.

Purpose: This exercise shows that try-catch around a thread’s start() call cannot catch exceptions thrown inside that thread, since it runs independently, and that UncaughtExceptionHandler is the correct mechanism for handling thread-level crashes.

Given Input: worker.start(); worker.join();

Expected Output:

Caught crash in thread 'Thread-0': Simulated crash in worker thread
Main thread continues normally

public class Main {
    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            throw new NullPointerException("Simulated crash in worker thread");
        });

        worker.setUncaughtExceptionHandler((thread, exception) -> {
            System.out.println("Caught crash in thread '" + thread.getName() + "': " + exception.getMessage());
        });

        worker.start();
        worker.join();
        System.out.println("Main thread continues normally");
    }
}Code language: Java (java)

Exercise 20: Error vs. Exception

Problem Statement: Write a program that deliberately triggers an OutOfMemoryError (e.g., creating an infinitely expanding list of large objects) or a StackOverflowError (infinite recursion). Try catching it using catch (Exception e). Observe why it fails to catch, and rewrite the catch block using Throwable or Error to intercept it (and discuss why catching Errors is generally bad practice).

Purpose: This closing exercise clarifies the split at the very top of the exception hierarchy: Exception and Error are separate branches under Throwable, so a catch (Exception e) block can never catch an Error, no matter how broad it looks.

Given Input: recurse(); (infinite recursion with no base case)

Expected Output: Caught: StackOverflowError

public class Main {
    public static void recurse() {
        recurse();
    }

    public static void main(String[] args) {
        // catch (Exception e) here would NOT catch the crash below,
        // because StackOverflowError extends Error, not Exception.
        try {
            recurse();
        } catch (Error e) {
            System.out.println("Caught: " + e.getClass().getSimpleName());
        }
    }
}Code language: Java (java)