All 15 Exceptions questions
More in Exceptions
What is the difference between checked and unchecked exceptions in Java, and how does the compiler treat each differently? 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 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 finally block's execution guarantee, and what are the specific edge cases where a finally block might NOT execute?

Intermediate

Answer

A finally block is guaranteed to execute after the corresponding try (and any matching catch) block completes, whether execution left normally, via a caught exception, an uncaught exception propagating out, or even a return/break/continue statement inside the try/catch -- the notable exceptions to this guarantee are: the JVM itself terminating abruptly (System.exit(), a JVM crash, or the process being killed), an infinite loop or blocking call within the try block that never actually returns control, or a Thread.stop() call (a deprecated, dangerous, unsafe method) -- outside these edge cases, finally is an extremely reliable guarantee for cleanup code.
public int riskyMethod() {
    try {
        return 1;
    } finally {
        System.out.println("finally still runs even though try already returned!");
        // Note: a return statement HERE would actually override/discard the try block's return value --
        // a well-known finally pitfall, generally considered bad practice
    }
}
Real-world example A resource-cleanup routine placed in a finally block reliably executes even when the corresponding try block's code throws an unexpected exception or returns early, EXCEPT in the rare case where the entire JVM process is forcibly terminated via System.exit() elsewhere in the code, an important edge case to be aware of for critical cleanup logic.

Common follow-ups: Why is returning a value from within a finally block considered a serious anti-pattern, and what confusing behavior does it cause?;How does try-with-resources' automatic close() interact with a finally block if both are present?

I/O & NIO;Error Handling
All 15 Exceptions questions