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 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 a common anti-pattern with catching exceptions too broadly (catch (Exception e) or worse, catch (Throwable t)), and why is it generally discouraged?

Intermediate

Answer

Catching an overly broad exception type (Exception, or especially Throwable, which also catches Errors like OutOfMemoryError that generally indicate unrecoverable JVM-level problems) risks silently swallowing exceptions the code has no genuine ability to meaningfully handle, masking real bugs (like an unexpected NullPointerException from a coding mistake being silently caught alongside an intentionally-handled, expected checked exception), making debugging significantly harder since the actual root cause of a problem gets hidden behind generic, non-specific catch-all handling -- best practice catches only the specific exception types the code can genuinely, meaningfully recover from, letting anything else propagate up to a level equipped to handle it (or a global handler) rather than being silently absorbed.
// Anti-pattern: overly broad catch swallows everything, including bugs
try {
    processOrder(order);
} catch (Exception e) {
    log.error("Something went wrong");  // swallows EVERYTHING, including NullPointerException bugs!
}

// Better: catch only the specific, genuinely-expected/recoverable exception
try {
    processOrder(order);
} catch (PaymentDeclinedException e) {
    notifyCustomerOfDeclinedPayment(order, e);
}
Real-world example A production bug where orders were silently failing without any visible error is eventually traced to a broad catch (Exception e) block that had been quietly swallowing an unrelated NullPointerException bug alongside the specific PaymentDeclinedException the code was actually intended to handle, masking the real defect for months.

Common follow-ups: Why is catching Throwable specifically considered even more dangerous than catching Exception?;What's an appropriate strategy for a truly generic, top-level 'catch anything and log it' handler (like a global exception handler) versus this specific anti-pattern?

Global Exception Handling & Middleware;Logging in Java (java.util.logging SLF4J Log4j)
All 15 Exceptions questions