Both Exception and Error are subclasses of Throwable, which is why they can both be thrown and caught in Java. But they represent fundamentally different kinds of problems, and treating them the same way is one of the most serious mistakes you can make in production code. An Exception signals something the application can and should respond to — a database is temporarily unavailable, a user supplied invalid input. An Error signals that the JVM itself is in trouble — memory is exhausted, the call stack has overflowed — and the application almost certainly cannot recover. Knowing which is which determines whether your catch block should retry, log and return, or simply stay out of the way.

What Are Exception and Error?

java.lang.Throwable is the root of everything that can be thrown or caught in Java. It has exactly two direct subclasses, and the design intent behind each is distinct.

java.lang.Throwable
    |
    +── java.lang.Error
    |       JVM and system-level failures
    |       The application did not cause these — the environment did.
    |       Recovery is almost always impossible.
    |       Subclasses include:
    |         OutOfMemoryError     — heap exhausted
    |         StackOverflowError   — infinite recursion or too-deep call stack
    |         VirtualMachineError  — JVM internal failure
    |         AssertionError       — assertion statement failed (-ea flag)
    |         ThreadDeath          — thread forcibly stopped (deprecated pattern)
    |         LinkageError         — class loading or bytecode mismatch
    |           └── NoClassDefFoundError
    |
    +── java.lang.Exception
            Application-level failures
            The program caused these — bad input, missing resource, logic error.
            Recovery is often possible and expected.
            |
            +── RuntimeException   ← UNCHECKED
            |       Programming mistakes — fix the code, do not catch these routinely
            |       ├── NullPointerException
            |       ├── IllegalArgumentException
            |       ├── IllegalStateException
            |       ├── ArrayIndexOutOfBoundsException
            |       ├── ClassCastException
            |       └── NumberFormatException
            |
            +── IOException        ← CHECKED
            |       Expected I/O failures — callers must handle or declare
            |       ├── FileNotFoundException
            |       └── SocketException
            |
            +── SQLException       ← CHECKED
            +── ClassNotFoundException  ← CHECKED
            +── InterruptedException    ← CHECKED

Basic Overview — Side-by-Side Comparison

FEATURE              ERROR                          EXCEPTION
────────────────────────────────────────────────────────────────────
Package              java.lang.Error                java.lang.Exception
Parent               java.lang.Throwable            java.lang.Throwable
Origin               JVM / system-level             Application / library code
Recoverability       Almost never recoverable       Often recoverable
Compiler enforcement Unchecked — no compile error   Checked subtypes enforced
                     if not caught                  Unchecked subtypes not enforced
Should you catch?    Almost never                   Yes — with appropriate strategy
Common examples      OutOfMemoryError               IOException, SQLException
                     StackOverflowError             IllegalArgumentException
                     NoClassDefFoundError           NullPointerException
When it occurs       JVM runs out of resources      Application logic failure
                     Class cannot be loaded         Bad input or missing data
                     Assertion fails                Network or file I/O problem
Typical response     Graceful shutdown attempt      Log, retry, return error response
                     (if anything is possible)

Understanding Error in Depth

Error represents conditions so severe that the JVM cannot guarantee that further execution is safe or meaningful. The three most common ones appear regularly in production environments and in technical interviews.

OutOfMemoryError

Thrown when the JVM cannot allocate an object because the heap is exhausted and the garbage collector cannot reclaim enough memory. Common causes: memory leaks from collections that grow without bound, loading excessively large datasets into memory at once, or simply an incorrectly sized heap for the application's workload.

Java

// File: OutOfMemoryDemo.java

import java.util.ArrayList;
import java.util.List;

public class OutOfMemoryDemo {

    public static void main(String[] args) {
        // Demonstrates the pattern that causes OutOfMemoryError
        // Run with: java -Xmx32m OutOfMemoryDemo to trigger it quickly
        System.out.println("Starting allocation loop...");
        List<byte[]> allocations = new ArrayList<>();

        try {
            // Each iteration allocates 1 MB — heap fills quickly with small -Xmx
            for (int count = 1; ; count++) {
                allocations.add(new byte[1024 * 1024]); // 1 MB per iteration
                System.out.println("Allocated " + count + " MB");
            }
        } catch (OutOfMemoryError error) {
            // Catching OutOfMemoryError is valid here — this is an educational demo
            // In production: catching OOME is acceptable ONLY for graceful shutdown
            // Do NOT attempt to continue business logic after OOME
            System.err.println("OutOfMemoryError caught: " + error.getMessage());
            System.err.println("Allocated blocks at time of failure: " + allocations.size());
            System.err.println("Triggering shutdown sequence...");
            allocations.clear(); // release references — let GC attempt recovery
        }

        System.out.println("Program continues — but reliability is questionable after OOME");
    }
}

Output:
Starting allocation loop...
Allocated 1 MB
Allocated 2 MB
...
Allocated 28 MB
OutOfMemoryError caught: Java heap space
Allocated blocks at time of failure: 28
Triggering shutdown sequence...
Program continues — but reliability is questionable after OOME

StackOverflowError

Thrown when the call stack exceeds its limit, almost always due to unbounded recursion — a recursive method that has no correct base case or a base case that is never reached for the given input.

Java

// File: StackOverflowDemo.java

public class StackOverflowDemo {

    // WRONG: no base case — recurses infinitely
    static int badFactorial(int n) {
        return n * badFactorial(n - 1); // never stops — StackOverflowError
    }

    // CORRECT: proper base case terminates the recursion
    static long goodFactorial(int n) {
        if (n <= 1) return 1; // base case — recursion stops here
        return n * goodFactorial(n - 1);
    }

    // Demonstrating how StackOverflowError propagates and can be caught
    static void demonstrateSOE() {
        try {
            int result = badFactorial(10_000); // triggers StackOverflowError
            System.out.println("Result: " + result); // never reached
        } catch (StackOverflowError error) {
            // Catching SOE is acceptable for detection and reporting only
            // The stack is corrupted at this point — do not attempt business logic
            System.err.println("StackOverflowError detected — likely infinite recursion");
            System.err.println("Check the call stack for the recurring method pattern");
        }
    }

    public static void main(String[] args) {
        demonstrateSOE();
        System.out.println();
        System.out.println("goodFactorial(10) = " + goodFactorial(10));
        System.out.println("goodFactorial(15) = " + goodFactorial(15));
    }
}

Output:
StackOverflowError detected — likely infinite recursion
Check the call stack for the recurring method pattern

goodFactorial(10) = 3628800
goodFactorial(15) = 1307674368000

NoClassDefFoundError

Thrown when the JVM successfully compiled a class reference but cannot find the class at runtime — typically a JAR is missing from the classpath or was present during compilation but removed before deployment.

WHEN NoClassDefFoundError OCCURS:

  At compile time:   com.example.PaymentService class exists — compilation succeeds
  At runtime:        payment-service-2.1.jar is not on the classpath — NCFE thrown

  Trace:
    java.lang.NoClassDefFoundError: com/example/PaymentService
        at com.example.OrderController.processPayment(OrderController.java:42)
        ...

  This is an Error, not an Exception — the JVM class loader failed.
  Distinguish from ClassNotFoundException (which IS an Exception, thrown
  when Class.forName() is called with a class name that is not found).

Understanding Exception in Depth

Exception represents failures that are part of the application's operational reality. The two most important subcategories — checked and unchecked — determine what the compiler requires and what design pattern is appropriate.

Checked Exceptions

These extend Exception without going through RuntimeException. The compiler enforces that callers either handle them with catch or declare them with throws. They represent expected, recoverable conditions — the kind of failure the calling code can reasonably be expected to have a strategy for.

Java

// File: CheckedExceptionDemo.java

import java.io.FileNotFoundException;
import java.io.IOException;
import java.sql.SQLException;

public class CheckedExceptionDemo {

    // IOException is checked — must be declared with throws or caught
    static String readConfig(String filePath) throws IOException {
        if (!filePath.endsWith(".properties")) {
            throw new FileNotFoundException(
                "Expected a .properties file, got: " + filePath);
        }
        // Simulate a successful read
        return "db.host=localhost\ndb.port=5432";
    }

    // SQLException is checked — must be handled or declared
    static void saveUser(String username) throws SQLException {
        if (username.contains("'")) {
            // Simulating a database driver rejecting the input
            throw new SQLException("Invalid character in username: " + username);
        }
        System.out.println("User saved: " + username);
    }

    public static void main(String[] args) {

        // Handling checked IOException
        try {
            String config = readConfig("application.txt"); // wrong extension
            System.out.println("Config: " + config);
        } catch (FileNotFoundException fnfe) {
            System.out.println("Config file issue: " + fnfe.getMessage());
        } catch (IOException ioe) {
            System.out.println("I/O failure: " + ioe.getMessage());
        }

        System.out.println();

        // Handling checked SQLException
        String[] usernames = {"priya_sharma", "rohan'; DROP TABLE users --", "ananya_iyer"};
        for (String username : usernames) {
            try {
                saveUser(username);
            } catch (SQLException sqlException) {
                System.out.println("DB error for [" + username + "]: " + sqlException.getMessage());
            }
        }
    }
}

Output:
Config file issue: Expected a .properties file, got: application.txt

User saved: priya_sharma
DB error for [rohan'; DROP TABLE users --]: Invalid character in username: rohan'; DROP TABLE users --
User saved: ananya_iyer

Unchecked Exceptions

These extend RuntimeException. The compiler does not require them to be handled or declared. They signal programming errors: calling a method on a null reference, accessing an invalid array index, passing a value that violates a method's documented contract. The right response to most RuntimeException subclasses is to fix the code, not write a catch block.

Java

// File: UncheckedExceptionDemo.java

import java.util.List;

public class UncheckedExceptionDemo {

    static double calculateDiscountedPrice(double originalPrice, int discountPercent) {
        // IllegalArgumentException: contract violation — fix the caller, do not catch this
        if (originalPrice < 0) {
            throw new IllegalArgumentException(
                "Price cannot be negative: " + originalPrice);
        }
        if (discountPercent < 0 || discountPercent > 100) {
            throw new IllegalArgumentException(
                "Discount must be between 0 and 100, got: " + discountPercent);
        }
        return originalPrice * (1 - discountPercent / 100.0);
    }

    static String getTopReview(List<String> reviews) {
        // NullPointerException prevention — validate before use
        if (reviews == null || reviews.isEmpty()) {
            return "No reviews available";
        }
        return reviews.get(0); // safe access after null and empty check
    }

    public static void main(String[] args) {

        System.out.println("=== Valid inputs ===");
        System.out.printf("Rs.1299 with 20%% off: Rs.%.2f%n",
            calculateDiscountedPrice(1299.0, 20));
        System.out.printf("Rs.499 with 0%% off: Rs.%.2f%n",
            calculateDiscountedPrice(499.0, 0));

        System.out.println();

        System.out.println("=== Contract violations caught for logging ===");
        // At the application boundary (API controller), catch unchecked to respond safely
        try {
            calculateDiscountedPrice(-100, 20);
        } catch (IllegalArgumentException exception) {
            // Only appropriate at the outermost layer — not inside business logic
            System.out.println("Bad request: " + exception.getMessage());
        }

        System.out.println();

        System.out.println("=== Null safety ===");
        System.out.println(getTopReview(null));
        System.out.println(getTopReview(List.of()));
        System.out.println(getTopReview(List.of("Great product!", "Fast delivery")));
    }
}

Output:
=== Valid inputs ===
Rs.1299 with 20% off: Rs.1039.20
Rs.499 with 0% off: Rs.499.00

=== Contract violations caught for logging ===
Bad request: Price cannot be negative: -100.0

=== Null safety ===
No reviews available
No reviews available
Great product!

How the JVM Handles Errors Differently

When an Exception propagates uncaught, the thread's uncaught exception handler logs it and terminates that thread. Other threads can continue running — the JVM process does not necessarily exit.

When an Error occurs, the situation is more severe. OutOfMemoryError affects heap memory that all threads share — after an OOME, no new objects can be allocated reliably in any thread. StackOverflowError corrupts the affected thread's execution state. The JVM does not enforce a special shutdown sequence for Errors, but the application is typically in an unreliable state.

EXCEPTION PROPAGATION vs ERROR IMPACT:

  RuntimeException propagation:
    Thread A: NullPointerException → uncaught → Thread A terminates
    Thread B: continues normally   — isolated to Thread A

  OutOfMemoryError:
    Thread A: OOME thrown          → memory exhausted for ALL threads
    Thread B: next object allocation attempt also fails
    Entire JVM process: compromised

  StackOverflowError:
    Thread A: SOE thrown           → Thread A's stack is in bad state
    Thread B: continues normally   — Thread B has its own stack
    (SOE is more contained than OOME, but Thread A should terminate)

  This is why the advice is different:
    Exception → catch, handle, recover, continue
    Error      → at most catch for graceful shutdown — do not continue

Real-World Example — Flipkart Payment Service Resilience

A payment service at Flipkart must distinguish between failures it can recover from and failures that indicate the system itself is in trouble. A database timeout is recoverable — retry or return an error response. A StackOverflowError caused by a recursive discount calculation with cyclic promotions indicates a data problem that requires a restart, not a retry.

Java

// File: PaymentProcessingException.java

// Checked — callers must handle payment failures explicitly
public class PaymentProcessingException extends Exception {

    private final String orderId;
    private final String failureReason;

    public PaymentProcessingException(
            String orderId, String failureReason, Throwable cause) {
        super("Payment failed for order " + orderId + ": " + failureReason, cause);
        this.orderId       = orderId;
        this.failureReason = failureReason;
    }

    public String getOrderId()     { return orderId;       }
    public String getFailureReason() { return failureReason; }
}

Java

// File: DiscountCalculator.java

import java.util.Set;

public class DiscountCalculator {

    private final Set<String> activePromotions;

    public DiscountCalculator(Set<String> activePromotions) {
        this.activePromotions = activePromotions;
    }

    // Recursive discount — will StackOverflow if promotion graph has cycles
    public double applyDiscount(String promotionCode, double basePrice, int depth) {
        if (!activePromotions.contains(promotionCode)) {
            return basePrice;
        }
        // Bug: cyclic promotions ("PROMO-A" → "PROMO-B" → "PROMO-A") cause SOE
        String linkedPromo = "PROMO-" + (char)('A' + (depth % 3)); // cycles at depth 3
        return applyDiscount(linkedPromo, basePrice * 0.9, depth + 1); // recursive call
    }
}

Java

// File: PaymentService.java

import java.util.Set;

public class PaymentService {

    private final DiscountCalculator discountCalculator;

    public PaymentService() {
        this.discountCalculator =
            new DiscountCalculator(Set.of("PROMO-A", "PROMO-B", "PROMO-C"));
    }

    public String processPayment(String orderId, double amount, String promoCode)
            throws PaymentProcessingException {

        double finalAmount;

        try {
            // Attempt discount calculation — may StackOverflow on cyclic promotions
            finalAmount = discountCalculator.applyDiscount(promoCode, amount, 0);
        } catch (StackOverflowError error) {
            // StackOverflowError: do NOT continue business logic
            // Log it as a system alert, skip the promotion, fail safe
            System.err.println(
                "[CRITICAL ALERT] StackOverflowError in discount calculation " +
                "for order " + orderId + " with promo " + promoCode +
                " — cyclic promotion detected. Billing at full price.");
            // Safe fallback: use the original price, skip the broken discount
            finalAmount = amount;
        }

        // Simulate payment gateway call — may fail with checked exception
        if (amount > 100_000) {
            throw new PaymentProcessingException(orderId,
                "Amount exceeds single-transaction limit: Rs." + amount,
                new RuntimeException("Gateway limit exceeded"));
        }

        return String.format("PAYMENT-CONFIRMED: order=%s amount=Rs.%.2f promo=%s",
            orderId, finalAmount, promoCode);
    }

    public static void main(String[] args) {

        PaymentService service = new PaymentService();

        System.out.println("=== Normal payment (no promotion) ===");
        try {
            System.out.println(service.processPayment("ORD-001", 1299.0, "NONE"));
        } catch (PaymentProcessingException ppe) {
            System.out.println("Payment failed: " + ppe.getMessage());
        }

        System.out.println();

        System.out.println("=== Payment with cyclic promotion (StackOverflowError) ===");
        try {
            // PROMO-A links to PROMO-B links to PROMO-A — infinite recursion
            System.out.println(service.processPayment("ORD-002", 2499.0, "PROMO-A"));
        } catch (PaymentProcessingException ppe) {
            System.out.println("Payment failed: " + ppe.getMessage());
        }

        System.out.println();

        System.out.println("=== Payment exceeding limit (PaymentProcessingException) ===");
        try {
            System.out.println(service.processPayment("ORD-003", 150_000.0, "NONE"));
        } catch (PaymentProcessingException ppe) {
            System.out.println("Payment failed [" + ppe.getOrderId() + "]: " +
                ppe.getFailureReason());
        }
    }
}

Output:
=== Normal payment (no promotion) ===
PAYMENT-CONFIRMED: order=ORD-001 amount=Rs.1299.00 promo=NONE

=== Payment with cyclic promotion (StackOverflowError) ===
[CRITICAL ALERT] StackOverflowError in discount calculation for order ORD-002 with promo PROMO-A — cyclic promotion detected. Billing at full price.
PAYMENT-CONFIRMED: order=ORD-002 amount=Rs.2499.00 promo=PROMO-A

=== Payment exceeding limit (PaymentProcessingException) ===
Payment failed [ORD-003]: Amount exceeds single-transaction limit: Rs.150000.0

Performance Considerations

Type	Common Examples	Cost of Creation	Recovery	Catch in application code?
`Error`	OutOfMemoryError, StackOverflowError	High (full stack trace)	Almost never	Only for graceful shutdown
`RuntimeException`	NPE, IllegalArgumentException	High (full stack trace)	Yes — fix the code or handle at boundary	At API/controller layer only
Checked Exception	IOException, SQLException	High (full stack trace)	Yes — expected recoverable failure	Always — compiler enforces it

Exception object creation is expensive regardless of type — the JVM captures the full stack trace at creation time. This is why using exceptions for flow control (throwing an exception to signal "not found" in a tight loop) degrades performance measurably. Both Error and Exception pay this cost.

Best Practices

Never catch Error unless you are implementing graceful shutdown logic. A catch (OutOfMemoryError e) in a service method that then tries to retry the operation is not recovery — it is false confidence in an unreliable state. The only legitimate use of catching Error is at the outermost application boundary to attempt to flush logs, close connections, and exit cleanly before the JVM dies anyway.

Never catch Throwable unless you have a very specific reason. catch (Throwable t) swallows both Error and Exception indiscriminately. The one acceptable place is in framework-level code that must intercept everything — a request dispatcher, a thread pool worker, a test framework. In application business logic, catch (Throwable t) is almost always a mistake.

Distinguish between Error and Exception in monitoring and alerting. An IOException might warrant a retry and a warning-level log. An OutOfMemoryError warrants an immediate page to on-call, a heap dump, and investigation of a memory leak. Treating them the same in your error logging pipeline means a JVM meltdown looks identical to a network hiccup in your dashboards.

Understand the difference between NoClassDefFoundError and ClassNotFoundException. Both relate to missing classes, but NoClassDefFoundError is an Error — the class was available at compile time but missing at runtime (deployment issue). ClassNotFoundException is a checked Exception — thrown by Class.forName() when the class name is not found on the classpath (expected condition the application can handle). Confusing these in an interview is a common mistake.

Common Mistakes

Mistake 1 — Catching Error and Continuing as Normal

Java

// WRONG — catches OutOfMemoryError and pretends the application can recover
public List<Order> loadAllOrders() {
    List<Order> orders = new ArrayList<>();
    try {
        for (Order order : database.fetchAllOrders()) {
            orders.add(order); // OOME thrown here when heap fills
        }
    } catch (OutOfMemoryError error) {
        System.out.println("Memory issue — returning partial list"); // dangerous!
        // The heap is still exhausted. The next allocation will also fail.
        // Returning a partial list implies the caller can trust this data.
    }
    return orders; // caller has no idea this is incomplete and unreliable
}

// CORRECT — either page in batches to avoid OOME, or let it propagate
public List<Order> loadOrdersBatch(int pageSize, int offset) throws DataAccessException {
    // Prevent OOME by design — never load unbounded data into memory
    return database.fetchOrders(pageSize, offset);
}

Mistake 2 — Catching Throwable in Business Logic

Java

// WRONG — catches Error AND Exception together in a service method
public String getProductName(String productId) {
    try {
        return productCatalog.findById(productId).getName();
    } catch (Throwable anything) {
        // Swallows StackOverflowError, OutOfMemoryError, NullPointerException —
        // everything — and returns a default value as if nothing happened
        return "Unknown Product"; // the application may be in a broken state
    }
}

// CORRECT — handle only what you can meaningfully handle
public String getProductName(String productId) {
    if (productId == null || productId.isBlank()) {
        throw new IllegalArgumentException("Product ID must not be blank");
    }
    Product product = productCatalog.findById(productId);
    return product != null ? product.getName() : "Product Not Available";
}

Mistake 3 — Confusing NoClassDefFoundError with ClassNotFoundException

Java

// ClassNotFoundException: thrown when using Class.forName() at runtime
// This IS an Exception (checked) — the application can handle it
public void loadDriverDynamically(String driverClass) {
    try {
        Class.forName(driverClass); // throws ClassNotFoundException if not on classpath
        System.out.println("Driver loaded: " + driverClass);
    } catch (ClassNotFoundException exception) {
        // Expected — ClassNotFoundException is a checked Exception
        System.out.println("Driver not found: " + driverClass);
        System.out.println("Add the driver JAR to the classpath.");
    }
}

// NoClassDefFoundError: class was on classpath at compile time but missing at runtime
// This IS an Error (unchecked) — almost always a deployment misconfiguration
// Do NOT catch this in application logic — fix the deployment

Mistake 4 — Treating All Errors as Fatal Without Any Response

Java

// WRONG — lets StackOverflowError crash the thread with no context in logs
public double computeRisk(String assetId, int depth) {
    if (assetId == null) return 0;
    return computeRisk(getLinkedAsset(assetId), depth + 1); // may overflow
}

// CORRECT — add a depth guard and catch SOE at the method boundary for diagnostic logging
public double computeRisk(String assetId, int depth) {
    if (depth > 500) {
        // Cyclic or overly deep asset graph — fail fast with a meaningful message
        throw new IllegalStateException(
            "Asset graph depth exceeded limit at assetId: " + assetId +
            " — possible cycle detected");
    }
    if (assetId == null) return 0;
    return computeRisk(getLinkedAsset(assetId), depth + 1);
}

String getLinkedAsset(String assetId) { return "linked-" + assetId; }

Interview Questions

Q1. What is the difference between Error and Exception in Java?

Both extend java.lang.Throwable, but they represent different problem categories. Exception signals application-level failures — database timeout, invalid input, missing file — that the program can and should handle. Error signals JVM or system-level failures — OutOfMemoryError, StackOverflowError, NoClassDefFoundError — where the JVM itself is in trouble and the application almost certainly cannot recover. The practical difference: you write catch (Exception e) blocks as part of normal error handling design; you write catch (Error e) only in shutdown hooks or framework-level code, and even then with extreme care.

Q2. Can you catch an Error in Java?

Syntactically, yes — catch (Error e) is valid Java. The compiler does not prevent it. But catching an Error and continuing business logic is almost always wrong. After an OutOfMemoryError, the heap is exhausted; the next allocation attempt may also fail. After a StackOverflowError, the affected thread's execution state is corrupted. The only defensible reason to catch an Error is to attempt a graceful shutdown — flush logs, close database connections, write a final diagnostic — before the JVM terminates. Catching Error to silently continue is one of the most dangerous patterns in production Java code.

Q3. What is the difference between NoClassDefFoundError and ClassNotFoundException?

ClassNotFoundException is a checked Exception thrown when Class.forName(), ClassLoader.loadClass(), or similar dynamic loading calls cannot find the specified class. It is expected and recoverable — the application can log it, fall back to a default, or report it clearly. NoClassDefFoundError is an Error thrown when a class that was present at compile time is missing at runtime — a JAR was not included in the deployment, or a class file was deleted. It is not recoverable in the traditional sense — it indicates a deployment or environment problem that needs human intervention, not application-level exception handling.

Q4. When would OutOfMemoryError occur in a production application?

OutOfMemoryError (specifically "Java heap space") occurs when the GC cannot reclaim enough memory to satisfy a new allocation request. Common production causes: collections that accumulate data over time without eviction (unbounded caches, growing queues), loading entire database result sets into memory, processing very large files fully in memory, or memory leaks in long-lived objects. The heap variant ("GC overhead limit exceeded") occurs when the JVM spends more than 98% of its time garbage collecting but reclaims less than 2% of the heap — effectively frozen. Production mitigation: heap profiling, bounded data structures, pagination over large datasets, and properly sized -Xmx settings.

Q5. What is StackOverflowError and how do you prevent it?

StackOverflowError occurs when a method call chain exceeds the JVM's thread stack depth limit — typically triggered by infinite recursion (a recursive method with no base case, or a base case that is never reached for the given input). Prevention strategies: ensure every recursive method has a correct, reachable base case; add a depth counter that throws IllegalStateException when a reasonable limit is exceeded; or convert deep recursion to iteration using an explicit Deque as a stack. In graph traversal and tree processing, unbounded recursion on large inputs is a known production risk even with correct base cases — iterative implementations are more robust.

Q6. Why is catching Throwable in application code dangerous?

Throwable is the parent of both Exception and Error. A catch (Throwable t) block swallows everything — database errors, null pointers, and OutOfMemoryError all pass through the same handler. This makes the application appear to handle errors gracefully when it may actually be in an unreliable state. After an OOME, no new objects can be allocated; after an SOE, the thread stack is compromised. Returning a "default value" in either case gives callers false confidence in data they should not trust. Framework code — request dispatchers, test runners, message consumers — sometimes catches Throwable to prevent one bad request from crashing a thread pool. In business logic, it is almost always a sign of unaddressed design problems.

Q7. What happens when an Error is not caught anywhere in the call stack?

The Error propagates all the way to the top of the call stack. At that point, the JVM invokes the thread's UncaughtExceptionHandler. The default handler prints the error type, message, and full stack trace to standard error and terminates the affected thread. If the affected thread is the main thread — or if it is a thread that no other thread was waiting on — the entire JVM process may exit with a non-zero status code. In a Spring Boot application, an uncaught OutOfMemoryError typically kills the entire service process, which is why proper heap sizing and monitoring are critical in production deployments.

FAQs

Is OutOfMemoryError an exception or an error in Java?

OutOfMemoryError is an Error — specifically a subclass of VirtualMachineError, which extends Error. It is not an Exception. The compiler does not require you to handle it, and in almost all cases you should not catch it in application code. The only appropriate response is to let the JVM terminate and then investigate the memory leak or heap sizing problem in post-mortem analysis.

What is the parent class of both Exception and Error in Java?

Both Exception and Error directly extend java.lang.Throwable. Throwable is the root of Java's entire exception hierarchy and is the only type that can be thrown with the throw statement or caught in a catch block. It provides the message, cause, and stack trace fields that all exceptions and errors carry.

Can StackOverflowError be prevented at the code level?

Yes — the most reliable prevention is ensuring recursive methods have correct, always-reachable base cases. For cases where the depth of recursion depends on external data (tree depth, graph edges), add an explicit depth counter and throw a descriptive IllegalStateException or IllegalArgumentException when a safe limit is exceeded. Converting recursion to iteration using an explicit stack (Deque) completely eliminates stack overflow risk for traversal algorithms.

What is AssertionError in Java?

AssertionError is thrown when an assert statement fails. Assertions are disabled by default and enabled with the -ea JVM flag. They are a development and testing tool — not a production error-handling mechanism. assert x > 0 : "x must be positive" throws AssertionError if x is not positive and assertions are enabled. Because assertions are disabled in production, you cannot rely on them for input validation in deployed code.

Why does Java have both Error and Exception instead of just one hierarchy?

The separation reflects a fundamental design principle: application code should handle application failures (Exception), and JVM failures (Error) are beyond the application's control. If Error were merged with Exception as checked exceptions, every method would need to declare throws OutOfMemoryError — the entire codebase would be polluted with exception declarations for things it can do nothing about. The separation keeps the signal clean: if a method declares throws IOException, that is a meaningful contract about recoverable failures. OutOfMemoryError needs no such declaration because the application cannot meaningfully respond to it.

What is the difference between a compile-time error and a runtime exception in Java?

A compile-time error is caught by the Java compiler before the program ever runs — missing semicolons, type mismatches, calling an undefined method. The program cannot execute at all until these are fixed. A runtime exception is a RuntimeException subclass that occurs during execution — NullPointerException, ArrayIndexOutOfBoundsException — when specific data conditions are met. The compiler cannot detect these because they depend on runtime values, not code structure. Runtime exceptions extend RuntimeException and are unchecked; they typically indicate programming mistakes that should be fixed rather than caught.

Summary

Exception and Error share a parent class but serve completely different purposes. Exception is the vocabulary of application failures — things the code caused, things the code can respond to, things callers should know about. Error is the vocabulary of JVM distress — things the environment did, things the code almost certainly cannot fix, things that typically warrant a restart rather than a retry.

The practical rules are clear. Catch exceptions with specific handlers at the appropriate layer. Design custom checked exceptions for recoverable domain failures. Use unchecked exceptions for programming contract violations. Catch Error only at the outermost boundary for graceful shutdown, and never in business logic. Never catch Throwable in application code.

For interviews, the three questions that come up most: the difference between NoClassDefFoundError and ClassNotFoundException (one is an Error, one is a checked Exception), why OutOfMemoryError should not be caught and continued, and what Throwable is and why catching it is dangerous. Knowing these demonstrates that you understand the JVM model, not just Java syntax.

What to Read Next

Topic	Link
How try, catch, and finally work with detailed syntax and all edge cases	Java try-catch →
The full difference between checked and unchecked exceptions and when to use each	Java Checked vs Unchecked Exceptions →
How throw and throws work and when to use each in method signatures	Java throw and throws →
When and how to build custom exception classes for domain-specific failures	Java Custom Exceptions →
What finally guarantees and when it does and does not execute	Java finally →

←

PreviousWhat is Exception Handling?

NextException Hierarchy

→