📦 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 ⬇️
Comments
Post a Comment