Checked Exception

A checked exception is one the compiler forces you to handle — you must either catch it or declare it with throws, or the code won't compile. In the class hierarchy, checked exceptions are subclasses of Exception but not of RuntimeException.

void readFile(String path) throws IOException {   // declared
    Files.readString(Path.of(path));              // may throw IOException (checked)
}

They represent recoverable, anticipated conditions outside your control — typically I/O, networking, or external resources (IOException, SQLException). The intent is to make the caller consciously decide how to handle a foreseeable failure.

The distinction and modern nuance interviewers want:

• Checked (Exception minus RuntimeException) → compiler-enforced; unchecked (RuntimeException and Error) → not enforced, usually programming bugs.
• Checked exceptions are controversial in modern Java: they don't compose well with lambdas/streams (a lambda can't throw a checked exception unless the functional interface declares it), so many current frameworks (notably Spring) favor unchecked exceptions and wrap checked ones (e.g. Spring's DataAccessException). So while you must know how checked exceptions work, the modern trend leans toward unchecked exceptions for cleaner, functional-style code.

You have two compiler-accepted options — handle it or propagate it:

1. Catch and handle with try-catch (use try-with-resources for closeables):

try (var reader = Files.newBufferedReader(path)) {
    return reader.readLine();
} catch (IOException e) {
    log.error("read failed", e);
    throw new ReadException("Could not read " + path, e);   // wrap & rethrow
}

1. Declare and propagate with throws, letting the caller deal with it:

String firstLine(Path path) throws IOException { ... }

Best practices interviewers reward:

• Don't swallow exceptions (empty catch blocks hide failures) — at minimum log; ideally handle or rethrow.
• Preserve the cause when wrapping (new XException(msg, e)) so the stack trace isn't lost.
• Use multi-catch (catch (IOException | SQLException e)) for shared handling, and try-with-resources to auto-close resources (replacing manual finally cleanup).
• Catch the most specific exception; never catch (Exception e) blindly.

A current note: because checked exceptions don't play well with lambdas/streams, a common pattern is to wrap them in an unchecked exception (or use a helper) inside functional code — so handling a checked exception sometimes means translating it to an unchecked one at the boundary.

Advantages

• Compiler-enforced handling — you can't accidentally ignore a foreseeable failure; the compiler makes you catch or declare it, which can improve reliability for genuinely recoverable conditions (I/O, network).
• Self-documenting API — a method's throws clause tells callers what can go wrong.

Disadvantages

• Boilerplate / clutter — propagating throws up many layers, or wrapping in try-catch, bloats code.
• Leaky abstractions — a low-level SQLException declared on an interface forces every caller to know about it; changing internals can ripple through signatures.
• Encourages bad habits — developers often swallow them (empty catch) or wrap in a generic RuntimeException just to satisfy the compiler, defeating the purpose.
• Poor fit with lambdas/streams — functional interfaces don't declare checked exceptions, so checked exceptions don't compose with map/forEach, forcing awkward wrapping.

The 2026 framing interviewers want: checked exceptions are increasingly seen as a misfeature. Modern Java style (and frameworks like Spring, which uses unchecked DataAccessException) favors unchecked exceptions for cleaner, stream-friendly code, reserving checked exceptions for truly recoverable, caller-actionable conditions. So know the trade-off and lean toward unchecked + meaningful wrapping in new code.

Common checked exceptions (subclasses of Exception but not RuntimeException), grouped by area:

• I/O — IOException and its subclasses FileNotFoundException, EOFException, InterruptedIOException.
• Database — SQLException (JDBC).
• Reflection / class loading — ClassNotFoundException, NoSuchMethodException, NoSuchFieldException.
• Concurrency — InterruptedException (thrown by Thread.sleep, join, blocking queue ops).
• Cloning / parsing — CloneNotSupportedException, ParseException.

try {
    Class.forName("com.example.Driver");   // ClassNotFoundException (checked)
    Thread.sleep(100);                     // InterruptedException (checked)
} catch (ClassNotFoundException | InterruptedException e) {
    Thread.currentThread().interrupt();    // proper handling for InterruptedException
}

A couple of points interviewers like: InterruptedException is a frequent one in concurrency questions — the correct handling is usually to restore the interrupt flag (Thread.currentThread().interrupt()) rather than swallow it. And contrast these with common unchecked ones (NullPointerException, IllegalArgumentException, ArrayIndexOutOfBoundsException), which the compiler does not force you to handle. Knowing which exceptions are checked vs unchecked — and that I/O, SQL, reflection, and interruption are the classic checked ones — is exactly what's being tested.

Technically you can make the compiler stop complaining with an empty catch block, but doing so is a serious anti-pattern — "swallowing" an exception hides real failures and produces silent, hard-to-debug bugs:

try {
    riskyIo();
} catch (IOException e) {
    // ❌ empty catch — DON'T do this; the failure vanishes silently
}

So the honest answer is: you should not ignore a checked exception. The compiler forces you to acknowledge it (catch or declare), but acknowledging it with an empty catch is bad practice. Proper options:

• Handle it meaningfully (recover, retry, fall back).
• Log it (at minimum) so the failure is visible.
• Rethrow/wrap it — preserving the cause — so a higher layer can deal with it: throw new AppException("...", e);

If a checked exception genuinely can't happen in your context, document why with a comment and rethrow it as an unchecked AssertionError/IllegalStateException rather than silently dropping it. Two related notes: for InterruptedException, "handling" means restoring the interrupt flag, not ignoring it; and a common reason people are tempted to swallow checked exceptions is that they don't fit lambdas/streams — the better fix there is to wrap them in an unchecked exception, not to silence them. The rule: never swallow exceptions.