💡Checked Exceptions in Java – The Good, The Bad & The Ugly (With Code Examples & Diagrams)

📦 Fun & Relatable Opening

Imagine your friend hands you a mystery box and says “Don’t open it without gloves.” That’s Java giving you a checked exception — it forces you to handle it before it explodes in your face. 😄

📜 What is a Checked Exception?

Checked exceptions are checked at compile time by the Java compiler.

💡 Examples: IOException, SQLException, ClassNotFoundException

public void readFile(String path) throws IOException {

    Files.readAllLines(Paths.get(path)); // IOException is checked

}

📊 Diagram: How Checked Exceptions Work

 [Method Call]

      |

      v

 [Throws Checked Exception]

      |

      +--> try { ... } catch(...) { ... }

      |

      +--> declare in method signature with throws

---

🛠 Advantages of Checked Exceptions (With Examples)

1️⃣ Compile-time Safety

public void loadData(String fileName) throws IOException {

    Files.readAllLines(Paths.get(fileName));

}

// Caller must handle IOException

try {

    loadData("data.txt");

} catch (IOException e) {

    System.out.println("File not found, loading defaults...");

}

✅ You’re forced to think about recovery instead of letting the app crash.

2️⃣ Explicit Documentation

public void connectToDb() throws SQLException { ... }

📜 Without reading docs, you already know database connectivity may fail.

3️⃣ Encourages Recovery

try {

    connectToDb();

} catch (SQLException e) {

    retryConnection();

}

4️⃣ Better API Clarity

👀 URL.openStream() clearly throws IOException so you know network issues are possible.

---

⚠️ Disadvantages of Checked Exceptions (With Examples)

1️⃣ Boilerplate Overload

try { method1(); } catch (IOException e) {}

try { method2(); } catch (SQLException e) {}

try { method3(); } catch (ClassNotFoundException e) {}

📝 Your code turns into a catch block jungle.

2️⃣ Leaks Abstraction

public void processOrder() throws SQLException {

    // Directly exposing database errors to upper layers

}

🕵️ Now even your UI layer must know about SQLException — tightly coupled.

3️⃣ Encourages Lazy Wrapping

public void doSomething() throws Exception { ... }

💤 No one knows what’s actually thrown — defeats the whole purpose.

4️⃣ Pain with Lambdas/Streams

📌 Checked exceptions don’t work smoothly inside lambdas because functional interfaces don’t declare them. This forces you to wrap or catch them inside the lambda.

// ❌ Compile error

files.forEach(file -> Files.readAllLines(file));

// ✅ Fixed

files.forEach(file -> {

    try {

        Files.readAllLines(file);

    } catch (IOException e) {

        System.out.println("Error reading file: " + file);

    }

});

5️⃣ Inflexible API Evolution

📌 Adding a checked exception to an existing method later will break all existing callers.

// Version 1

public void read() { ... }

// Version 2

public void read() throws IOException { ... } // Now all callers must change

---

💡 Try-Catch vs Throws — Your Choice

Checked Exception Found

       |

   [Your Choice]

   /           \

try-catch     throws

📜 Option 1: Using throws

public void readFile1() throws IOException {

    Files.readAllLines(Paths.get("data.txt"));

}

📌 Passes the responsibility to the caller.

🛠 Option 2: Using try-catch

public void readFile2() {

    try {

        Files.readAllLines(Paths.get("data.txt"));

    } catch (IOException e) {

        System.out.println("Handled inside method: " + e.getMessage());

    }

}

📌 Handles it right away, hiding from the caller.

Golden Rule: Catch if you can recover meaningfully, otherwise throws and let someone else decide.

---

😂 Wrapping Up

Checked exceptions are like your mom’s warnings before a trip — you can’t leave the house until you acknowledge them. 😄

What’s your take — are you Team Checked or Team Unchecked? Drop your thoughts below ⬇️