---

🟢 Junior Level

In synchronous code, errors are handled using traditional try-catch-finally blocks. In CompletableFuture, computations execute asynchronously across different worker threads, meaning a surrounding try-catch block around the chain initialization cannot intercept runtime failures occurring inside asynchronous tasks.

To handle errors declaratively, CompletableFuture provides three core methods:

1. exceptionally(Function<Throwable, T> fallback) (analogous to catch):
   • Invoked only when an exception occurs.
   • Intercepts the failure and returns a default fallback value of type T, restoring the pipeline to normal execution.
2. handle(BiFunction<T, Throwable, R> fn) (universal transformer):
   • Invoked always — both on success and on failure.
   • Inspects both arguments (result and throwable) and transforms the outcome into a new type R.
3. whenComplete(BiConsumer<T, Throwable> action) (analogous to finally):
   • Invoked always to execute side effects (logging, closing resources, telemetry metrics).
   • Does not modify the result or exception of the stage (transparent observer).

Code Example

CompletableFuture.supplyAsync(() -> {
    if (new Random().nextBoolean()) {
        throw new IllegalStateException("Remote service failed");
    }
    return "Valid response";
})
// Catch error and return a safe fallback value:
.exceptionally(ex -> {
    System.err.println("Error encountered: " + ex.getMessage());
    return "Cached fallback";
})
// The next stage receives either the normal result or the fallback:
.thenAccept(data -> System.out.println("Result: " + data));

---

🟡 Middle Level

The CompletionException Wrapper

Any checked or runtime exception thrown inside a stage lambda is automatically wrapped by the runtime inside a java.util.concurrent.CompletionException:

CompletableFuture.supplyAsync(() -> {
    throw new IllegalArgumentException("Invalid ID");
}).exceptionally(ex -> {
    // ex is a CompletionException wrapping the real error
    Throwable rootCause = (ex instanceof CompletionException) ? ex.getCause() : ex;
    System.out.println("Root cause: " + rootCause.getClass().getSimpleName()); // IllegalArgumentException
    return "Default Value";
});

Pipeline Short-Circuiting

When an exception occurs at any intermediate stage:

1. All subsequent standard data transformation stages (thenApply, thenAccept, thenCompose) are immediately skipped.
2. The pipeline remains in an exceptional state until a recovery node (exceptionally or handle) is reached.
3. Once recovered, subsequent standard stages resume normal execution.

CompletableFuture.supplyAsync(() -> "Step 1")
    .thenApply(s -> { 
        throw new RuntimeException("Crash"); // Step 2 fails
    })
    .thenApply(s -> s + " -> Step 3") // SKIPPED!
    .thenApply(s -> s + " -> Step 4") // SKIPPED!
    .exceptionally(ex -> "Recovered") // Catches error and restores pipeline!
    .thenApply(s -> s + " -> Step 5") // EXECUTES: "Recovered -> Step 5"
    .thenAccept(System.out::println);

Asynchronous Fallbacks: exceptionallyCompose (Java 12+)

Prior to Java 12, exceptionally only permitted returning a synchronous value $T$. If error recovery required calling a secondary asynchronous service, cumbersome workarounds were required.

Java 12 added exceptionallyCompose (the error equivalent of thenCompose):

primaryService.fetchDataAsync(id)
    .exceptionallyCompose(ex -> {
        log.warn("Primary service unreachable, failing over to backup...", ex);
        return backupService.fetchDataAsync(id); // Returns CompletableFuture<Data>
    });

---

🔴 Senior Level

Internal Propagation Mechanics: AltResult and postComplete

CompletableFuture does not use JVM stack unwinding for asynchronous error propagation:

1. When a task in an executor throws Throwable t, the internal runner catches it via catch (Throwable ex).
2. It constructs an internal marker: AltResult(ex instanceof CompletionException ? ex : new CompletionException(ex)).
3. The internal result field is atomically updated to this AltResult instance using CAS.
4. postComplete() traverses the dependent Treiber stack. For stages like UniApply, UniAccept, and UniCompose, their tryFire() implementation checks if (result instanceof AltResult). If true, the user lambda is not invoked; instead, the AltResult reference is propagated directly to the downstream stage.
5. Only recovery stages (UniExceptionally, UniHandle) intercept AltResult, unpack the underlying exception, and pass it to user code.

Exception Conflicts in whenComplete: Suppressed Exceptions

The whenComplete method takes a BiConsumer<T, Throwable>. What happens if the antecedent future failed with exception $E_1$, and the consumer lambda inside whenComplete throws another exception $E_2$?

CompletableFuture preserves both exceptions using Java’s suppressed exception mechanism:

CompletableFuture<String> cf = CompletableFuture.failedFuture(new IOException("Disk read error"));

CompletableFuture<String> result = cf.whenComplete((val, ex) -> {
    throw new IllegalStateException("Metrics logging crashed");
});

try {
    result.join();
} catch (CompletionException e) {
    Throwable cause = e.getCause(); // IllegalStateException (from whenComplete)
    Throwable[] suppressed = cause.getSuppressed(); // Contains IOException ("Disk read error")!
}

The exception thrown from whenComplete takes precedence as the primary cause, while the antecedent exception is attached via addSuppressed().

Root Cause Unwrapping Utility

In complex distributed architectures, exceptions can be wrapped multiple times in nested CompletionException and ExecutionException layers:

public static Throwable unwrap(Throwable ex) {
    Throwable current = ex;
    while (current instanceof CompletionException || current instanceof ExecutionException) {
        if (current.getCause() == null) break;
        current = current.getCause();
    }
    return current;
}

---

4 Tricky Questions

1. What happens if a new unchecked exception is thrown inside an .exceptionally(fn) lambda?

Answer: If the exceptionally handler itself throws an exception, the returned CompletableFuture transitions to an exceptional state containing the new exception (wrapped in CompletionException). The original antecedent error is superseded, and the new exception cascades downstream until intercepted by another downstream exceptionally or handle stage.

2. What is the difference in exception behavior between cf.join() and cf.get()?

Answer:

• get() is defined in Future<T>. On failure, it throws the checked exception ExecutionException, requiring an explicit try-catch (ExecutionException | InterruptedException e). If interrupted while waiting, it throws InterruptedException.
• join() is defined in CompletableFuture<T>. On failure, it throws the unchecked exception CompletionException. If interrupted, the calling thread’s interrupt status is restored via Thread.currentThread().interrupt(), and a CompletionException(new InterruptedException()) is thrown. This makes join() ergonomic within Stream API pipelines.

3. Does .whenComplete(action) execute if the CompletableFuture is cancelled via cf.cancel(true)?

Answer: Yes, it executes unconditionally. Cancellation in CompletableFuture is modeled as exceptional completion with java.util.concurrent.CancellationException. In the whenComplete((res, ex) -> ...) callback, res will be null and ex will contain an instance of CancellationException. This ensures resources, file handles, and network sockets are reliably cleaned up even upon cancellation.

4. How can you implement an asynchronous fallback (calling a secondary service) in Java 8 prior to exceptionallyCompose?

Answer: In Java 8, this was achieved by combining handle with manual flattening using thenCompose:

// Java 8 asynchronous fallback pattern:
primaryService.fetchAsync()
    .handle((res, ex) -> {
        if (ex != null) {
            return backupService.fetchAsync(); // Returns CompletableFuture<Data>
        }
        return CompletableFuture.completedFuture(res);
    })
    .thenCompose(Function.identity()); // Flattens CompletableFuture<CompletableFuture<Data>>

Java 12 replaced this cumbersome two-step pattern with native exceptionallyCompose.

---

🎯 Interview Cheat Sheet

Summary in 60 Seconds

• Asynchronous exceptions skip normal transformation stages (thenApply, thenAccept) and are encapsulated in CompletionException.
• exceptionally(fn) acts like catch: runs only on error, returns fallback value.
• handle(fn) acts as a universal stage: runs on both success and failure, returns new transformed value.
• whenComplete(action) acts like finally: runs on both outcomes for side effects; does not alter return values or swallow errors. If it throws an exception, the original error is attached as a suppressed exception.
• Use exceptionallyCompose (Java 12+) to trigger an asynchronous fallback service upon error.

Common Interview Mistakes

• Expecting whenComplete to swallow exceptions or return fallback values (it accepts BiConsumer and returns void).
• Confusing checked ExecutionException thrown by get() with unchecked CompletionException thrown by join().
• Assuming cancellation bypasses whenComplete (it triggers whenComplete with CancellationException).

Related Questions

• What is the Difference Between handle(), exceptionally() and whenComplete()
• What Happens If an Exception Occurs in CompletableFuture Chain
• How to Implement Retry Logic with CompletableFuture
• What Does join() Method Do and How Does It Differ from get()