Checked vs Unchecked Exception.

Hook: Interviewers love this question because it reveals whether you know what Java enforces at compile time versus what it only reports at runtime.

Question: What is the difference between checked and unchecked exceptions in Java?

Answer: Checked exceptions are validated by the compiler, so you must either catch them or declare them with throws. Unchecked exceptions are subclasses of RuntimeException and do not need to be handled at compile time. In practice, checked exceptions usually mean expected external failures, while unchecked exceptions usually mean a bug or invalid input.

Interview-Ready Answer: In Java, checked exceptions are enforced by the compiler: if a method can throw one, I must catch it or declare it. Unchecked exceptions are subclasses of RuntimeException, so the compiler does not force handling, although they can still crash the program at runtime. I use checked exceptions for situations a caller can reasonably recover from, like file or network failures, and unchecked exceptions for programming mistakes like bad arguments or null values.

What the terms mean

In Java, every exception is a Throwable, which is the base type for things that can be thrown. The important split is this: a checked exception is any subclass of Exception that is not a RuntimeException, and an unchecked exception is either a RuntimeException or an Error. The compiler enforces checked exceptions; the JVM does not treat them differently at runtime.

How Java enforces checked exceptions

1. You call a method that declares a checked exception, such as throws IOException.
2. The compiler checks whether that exception is caught in a try/catch block or passed upward with throws.
3. If neither is true, compilation fails with a message like “unreported exception ...; must be caught or declared to be thrown”.
4. If the exception actually occurs, the JVM creates the exception object, captures the stack trace, and unwinds the call stack until a matching catch block is found.
5. If nobody catches it, the thread ends and the default handler prints the stack trace.

Comparison at a glance

When to use each

1. Use checked exceptions when the caller can recover in a meaningful way: retry a file read, ask the user for a new path, or choose another server.
2. Use unchecked exceptions for programming mistakes: bad arguments, null values, illegal state, or broken invariants.
3. For library design, prefer a small number of meaningful checked exceptions instead of forcing callers to write catch(Exception) everywhere.

One important edge case: overriding methods cannot broaden checked exceptions. A subclass method can throw fewer checked exceptions, or more specific ones, but not a wider checked exception than the parent method declares. Since Java 7, try-with-resources also reduced the pain of checked exceptions by closing resources automatically and allowing suppressed exceptions to be attached to the main failure.

Performance and gotchas

Throwing an exception is much more expensive than a normal if check because stack-trace creation and stack unwinding are involved. The cost grows with call depth, so think of it as roughly proportional to the number of frames the exception must pass through. That is why exceptions are for exceptional situations, not routine branching.

Memory model: the rule is compile-time, but the mechanism is runtime stack unwinding. That is the key interview point: the JVM throws everything the same way, but the compiler only forces you to deal with checked exceptions.

Real-World Story: In a checkout service for an e-commerce site, the code calls a payment gateway and then writes an order record. The HTTP client can fail with a checked exception such as an I/O problem, because the caller may retry or route to a backup gateway. But validation problems like a negative amount or a missing cart item should be unchecked, because those are bugs or bad input that should be fixed before payment starts.

What goes wrong when teams misunderstand this? A developer catches a broad Exception, logs it, and still marks the order as paid. Under load, the payment call starts timing out, logs fill with java.io.IOException: connection reset, and customers see duplicate charges or “paid” orders that never shipped. The bug shows up as rising retries, stuck orders in PENDING, and support tickets saying “I was charged but my order disappeared.”

Follow-up & Tricky Questions:

• When should I use a checked exception in API design? Use it when the caller has a realistic recovery action, like retrying, asking for a file path, or switching to a fallback. If the caller cannot do anything useful, an unchecked exception is usually cleaner.
• Can an overriding method throw a broader checked exception? No. It may throw the same checked exception, a narrower one, or none at all, but not a wider checked exception than the parent method.
• Is it okay to catch Exception? Usually only at the top boundary of an app, where you log and convert to a user-facing error. Inside business logic, catching Exception often hides bugs and makes debugging harder.
• Why is NullPointerException unchecked? Because it usually signals a programmer mistake, not a recoverable external failure. Java wants you to fix the code, not add boilerplate every time a null slips through.
• What is the difference between Exception and RuntimeException? RuntimeException is a subclass of Exception, but exceptions under it are treated as unchecked. That is why the hierarchy alone is not enough; the exact subclass matters.
• Is Error checked or unchecked? Error is unchecked, but it usually represents serious JVM problems such as OutOfMemoryError. In interviews, it is good to say that application code normally should not try to recover from it.
• Can I throw a checked exception from a lambda? Usually not directly, because most standard functional interfaces do not declare checked exceptions. In practice, developers either handle it inside the lambda or wrap it in an unchecked exception.
• If an exception is unchecked, does that mean it is never handled? No. It only means the compiler does not force handling. You can still catch it at a boundary if you want controlled failure behavior.

Tricky / gotcha questions:

• Are all subclasses of Exception checked? No. RuntimeException and its subclasses are the big exception to that rule.
• Do checked and unchecked exceptions behave differently inside the JVM? No. The difference is mostly compile-time enforcement, not a different runtime throwing mechanism.
• Can a method avoid declaring a checked exception if it calls another method that throws one? Only if it catches that exception itself. Otherwise it must declare or handle it.

Common Mistakes:

• Mistake: Saying checked means “important” and unchecked means “unimportant.” Correction: The real difference is compiler enforcement, not importance.
• Mistake: Catching every exception and continuing as if nothing happened. Correction: Handle only what you can recover from; otherwise fail fast or rethrow with context.
• Mistake: Using checked exceptions for every validation problem. Correction: Reserve them for cases where the caller can make a meaningful recovery choice.
• Mistake: Assuming unchecked exceptions do not need attention. Correction: They still need handling at boundaries, especially in web controllers, message consumers, and background jobs.

Memory Hook: Think of checked exceptions as a compiler checkpoint: the compiler checks your ticket before you pass. Unchecked exceptions are runtime potholes: Java lets you drive on, but the road can still break under you.

Cheat Sheet:

• Checked = must catch or declare.
• Unchecked = RuntimeException and Error.
• Checked is usually for recoverable, external problems.
• Unchecked is usually for bugs, invalid arguments, or illegal state.
• Throwing exceptions is expensive compared with normal branching.
• The compiler enforces the rule; the JVM only throws the object at runtime.

Practice Tasks:

• Write a custom checked exception for a file loader, then force the caller to handle missing files gracefully.
• Refactor a method that throws IllegalArgumentException for bad input and explain why it should stay unchecked.
• Add a second operation to the bank account example, such as deposit, and decide which failures should be checked versus unchecked.