All 15 Exceptions questions
More in Exceptions
What is the basic syntax and control flow of a try-catch-finally block, and what determines which catch block (if multiple exist) handles a thrown exception? What is the correct usage of try-with-resources, and how does it automatically ensure a resource's close() method is called even if an exception occurs? What is a common anti-pattern with catching exceptions too broadly (catch (Exception e) or worse, catch (Throwable t)), and why is it generally discouraged? What is the finally block's execution guarantee, and what are the specific edge cases where a finally block might NOT execute? What is the multi-catch syntax (catch (IOException | SQLException e)) introduced in Java 7, and what restriction applies to the exception types combined in a single multi-catch block? What is the difference between Error and Exception in Java's Throwable hierarchy, and why should application code generally avoid catching Error subclasses like OutOfMemoryError or StackOverflowError? How do you create and throw a custom exception class, and what constructors should a well-designed custom exception typically provide? What is the purpose of the addSuppressed() mechanism and getSuppressed() method on Throwable, and in what specific scenario does the JVM automatically populate suppressed exceptions? How does exception chaining (via the cause mechanism, initCause() or a constructor accepting a Throwable) preserve the original root-cause exception when wrapping and rethrowing a different exception type, and why does this matter for debugging? How would you design a custom exception hierarchy for an application, deciding when to create new exception classes versus reusing existing ones, and what fields/context should a well-designed custom exception carry?
Advertisement
Java › Exceptions

What is the difference between checked and unchecked exceptions in Java, and how does the compiler treat each differently?

Beginner

Answer

Checked exceptions (subclasses of Exception but not RuntimeException, like IOException) must either be caught or explicitly declared in a method's throws clause, enforced by the compiler at compile time -- representing conditions a well-behaved caller should anticipate and handle; unchecked exceptions (subclasses of RuntimeException, like NullPointerException or IllegalArgumentException) require no such compile-time declaration or handling, typically representing programming errors or conditions the caller usually can't reasonably recover from, letting them propagate freely up the call stack without cluttering every intermediate method's signature.
// Checked exception -- must be caught or declared
public void readFile(String path) throws IOException {
    Files.readString(Path.of(path));  // IOException is checked, compiler enforces handling
}

// Unchecked exception -- no compiler enforcement
public int divide(int a, int b) {
    return a / b;  // ArithmeticException is unchecked, no throws declaration required
}
Real-world example A file-processing method's throws IOException declaration forces every calling method up the chain to either handle the exception or explicitly propagate it further, ensuring file I/O failures can never be silently ignored by accident, unlike an unchecked NullPointerException which requires no such compile-time acknowledgment.

Common follow-ups: Why has the Java community increasingly moved away from checked exceptions in newer API designs, like the Streams API?;What determines whether a new custom exception class should extend Exception or RuntimeException?

Error Handling;Java Fundamentals: Syntax Data Types & Operators
All 15 Exceptions questions