Checked vs Unchecked Exceptions

#What are Checked and Unchecked Exceptions?

Java classifies exceptions into two major categories:

The biggest difference is who is responsible for handling them.

#Why Did Java Introduce Checked Exceptions?

Imagine reading a file:

Files.readString(Path.of("data.txt"));

Many things can go wrong:

• The file doesn't exist
• No permission
• Disk failure
• Network failure (remote file systems)

The compiler forces the programmer to think about these situations. This improves program reliability.

#Checked Exceptions

A checked exception is an exception that the compiler checks during compilation. If it's not handled, compilation fails.

import java.io.*;

public class Demo {
    public static void main(String[] args) {
        FileReader reader = new FileReader("test.txt");
    }
}

Unhandled exception type FileNotFoundException

Handling Checked Exceptions

Option 1 — try-catch:

try {
    FileReader reader = new FileReader("test.txt");
} catch (FileNotFoundException e) {
    System.out.println("File not found");
}

Option 2 — throws:

public static void main(String[] args) throws FileNotFoundException {
    FileReader reader = new FileReader("test.txt");
}

Now the responsibility moves to the caller.

Common Checked Exceptions

IOException, SQLException, ClassNotFoundException, FileNotFoundException, InterruptedException, ParseException, CloneNotSupportedException.

#Unchecked Exceptions

Unchecked exceptions occur during runtime. The compiler does not force you to handle them.

public class Demo {
    public static void main(String[] args) {
        int x = 10 / 0;
    }
}

Compiles successfully. At runtime:

ArithmeticException: / by zero

Another example:

String name = null;
System.out.println(name.length());

NullPointerException

The compiler allows it.

Why Doesn't Java Force Runtime Exceptions?

Because these are considered programming mistakes.

String name = null;
name.length();

The compiler cannot always determine whether name will be null at runtime. Similarly:

int[] arr = new int[5];
System.out.println(arr[100]);

The compiler cannot predict runtime values.

Common Runtime Exceptions

NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, NumberFormatException, IllegalArgumentException, IllegalStateException, ClassCastException, UnsupportedOperationException, ConcurrentModificationException.

These are the exceptions interviewers expect every Java developer to know.

#Checked vs Unchecked Comparison

#Exception Hierarchy Revisited

A simple rule:

#Compiler Behaviour

#throws Keyword

public void read() throws IOException {
}

This means: "I may throw IOException. The caller must handle it." The method is not handling the exception — it is only declaring it.

#Exception Propagation

class Demo {
    static void readFile() throws IOException {
        throw new IOException();
    }

    static void process() throws IOException {
        readFile();
    }

    public static void main(String[] args) {
        try {
            process();
        } catch (IOException e) {
            System.out.println("Handled");
        }
    }
}

#Overriding Rules

class Parent {
    void read() throws IOException {
    }
}

Valid child:

class Child extends Parent {
    @Override
    void read() throws FileNotFoundException {
    }
}

Because FileNotFoundException is a subclass of IOException.

Invalid child:

class Child extends Parent {
    @Override
    void read() throws Exception {   // Compilation error
    }
}

Reason: a child class cannot throw a broader checked exception than the parent method declares. (Overriding rules are covered in depth in their own chapter.)

#When to Use Which

Use checked exceptions when

• Reading files
• Database operations
• Network communication
• Reflection
• External APIs
• Recoverable situations

public void uploadFile() throws IOException

Use unchecked exceptions for

• Invalid method arguments
• Null values
• Programming errors
• Business validation failures (commonly in enterprise applications)
• Incorrect object state

throw new IllegalArgumentException("Age cannot be negative");

#Enterprise Spring Boot Perspective

Most modern Spring Boot applications prefer unchecked exceptions for business logic.

public User findUser(Long id) {
    return repository.findById(id)
            .orElseThrow(() -> new UserNotFoundException("User not found"));
}

class UserNotFoundException extends RuntimeException {
}

Why?

• Cleaner method signatures
• Less boilerplate
• Better readability
• Centralized exception handling using @ControllerAdvice

Checked exceptions are still common for file handling, I/O, third-party libraries and low-level APIs.