A checked exception is the right choice when you want the compiler to force callers to acknowledge and handle a recoverable, expected failure condition, rather than letting it fail silently until it surfaces unexpectedly at runtime.
Key Points: • Checked exceptions are ideal for operations with predictable external failure modes, like file I/O or database access, where the caller has a reasonable chance to recover by retrying, falling back, or informing the user. • IOException and SQLException are standard examples: reading a file that doesn't exist or a query hitting a connectivity issue are conditions a caller should plan for, not ignore. • Forcing a catch, or a declared throws clause, documents the failure mode directly in the method signature, making the API self-describing for callers. • Unchecked exceptions are better suited for programming errors, like NullPointerException or IllegalArgumentException, that indicate a bug rather than an expected, recoverable condition.
Example: A method that reads and parses a configuration file might declare throws IOException, forcing every caller to explicitly decide whether to propagate the failure, retry with a default file, or surface an error to the user, rather than letting a missing file crash the application unexpectedly.
Interview Tip: A concise interview answer is:
"I'd use a checked exception when a failure is expected and recoverable, like a file not being found or a database call failing, since it forces the caller to explicitly handle it. I'd reserve unchecked exceptions for programming errors like invalid arguments or null references, where the failure indicates a bug rather than something the caller should be expected to recover from."