All 15 Exceptions questions
More in Exceptions
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? 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? How does exception handling interact with performance, particularly regarding the cost of filling in a stack trace, and how would you optimize exception usage in a performance-critical hot path? How would you implement a custom checked exception that requires additional context to be attached as the exception propagates up multiple layers of a call stack, without losing information at each layer?
Advertisement
Java › Exceptions

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?

Intermediate

Answer

Both Error and Exception extend the common Throwable superclass, but Error is specifically reserved for serious, generally unrecoverable conditions typically caused by the JVM/environment itself running out of critical resources or hitting a fundamental limit (OutOfMemoryError, StackOverflowError, LinkageError) rather than an application-level failure condition; catching these is generally discouraged (though technically possible, since they're not enforced as checked) because the JVM's own internal state may already be significantly compromised by the time such an Error is thrown (for example, after an OutOfMemoryError, there may not be enough free memory remaining to even execute a meaningful recovery/cleanup routine), making genuine recovery unreliable at best and potentially masking a severe underlying problem that should instead cause the application to fail fast and restart cleanly.
try {
    performRecursiveOperation();
} catch (StackOverflowError e) {  // technically legal, but generally a bad idea
    log.error("Stack overflow occurred", e);
    // The JVM's stack state at this point may be in a precarious condition;
    // "recovering" and continuing normal operation is often unreliable
}
Real-world example A team debugging a service that behaves erratically after briefly catching and 'handling' an OutOfMemoryError (attempting to continue normal operation rather than restarting) discovers the JVM's internal state was left in a subtly corrupted condition by the near-exhaustion event, leading them to instead let such Errors propagate uncaught and rely on process supervision (like Kubernetes) to restart the instance cleanly.

Common follow-ups: Are there any legitimate, narrow scenarios where catching a specific Error subclass is genuinely appropriate?;How does this distinction between Error and Exception inform designing a global/top-level exception handler's scope?

JVM JRE & Memory;Garbage Collection
All 15 Exceptions questions