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 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
Back to results for “Exception Handling”
Java › 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?

Beginner

Answer

A try block contains code that might throw an exception; one or more catch blocks (each specifying a particular exception type) follow, with the JVM checking them in declared order and executing the FIRST catch block whose declared type matches (via instanceof-style checking) the actual thrown exception's type -- meaning catch blocks should generally be ordered from most specific to most general (a more general catch block declared before a more specific one would make the specific one unreachable, which the compiler actually flags as an error); an optional finally block always executes afterward regardless of what happened.
try {
    riskyOperation();
} catch (FileNotFoundException e) {  // more specific, checked first
    handleMissingFile(e);
} catch (IOException e) {  // more general, only reached if NOT a FileNotFoundException
    handleGeneralIOError(e);
} finally {
    cleanup();
}
Real-world example A file-processing method with a specific catch (FileNotFoundException e) block preceding a more general catch (IOException e) block correctly routes a missing-file scenario to specialized handling (suggesting the correct file path to the user) while still catching any other I/O failure through the general handler, relying on the JVM's declared-order matching.

Common follow-ups: What compiler error occurs if you accidentally place a more general catch block before a more specific one?;How would you determine the exact runtime type of a caught exception if the catch block declares a general supertype?

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