How can a CompletableFuture silently swallow an exception, and what practices ensure failures are observed?

## Background: how a CompletableFuture fails A `CompletableFuture<T>` completes in one of two ways: **normally** (with a value) or **exceptionally** (with a `Throwable`). When the lambda you pass to `supplyAsync` or `thenApply` throws, the framework *catches* that throwable and uses it to complete the future exceptionally — it does **not** propagate up the call stack at that moment, because the lambda is running on some pool thread, not your call site. So the throwable is now *stored inside the future object*. Whether anyone ever learns about it depends entirely on whether the result is **consumed**. ## The three ways a failure becomes visible 1. **Blocking accessors** — `join()` rethrows the throwable wrapped in an unchecked `CompletionException`; `get()` wraps it in a checked `ExecutionException`. This is the most direct way: if you join, you'll see it. 2. **Error-handling stages** — `exceptionally(fn)` runs `fn` with the throwable if upstream failed (and lets you substitute a fallback value); `handle((v, ex) -> ...)` always runs and gets both value and exception; `whenComplete((v, ex) -> ...)` observes both as a side-effect and *re-raises* the original outcome (it does not swallow). 3. **Downstream propagation** — an exceptional completion flows *down* the chain: dependent stages like `thenApply` are skipped and the exception is passed along until something handles it or the chain ends. ## The pitfall: nobody consumes the result Consider: ```java CompletableFuture.supplyAsync(this::loadData) // throws inside .thenApply(this::transform); // skipped on failure // ...and we never join, never handle. Method returns void. ``` Here the exception completes the future exceptionally, `thenApply` is skipped, and the resulting future — *which we never assigned, joined, or handled* — becomes unreachable and is eventually garbage-collected. **No stack trace is printed, no log line appears, nothing crashes.** This is the silent-swallow. Unlike a raw thread (whose escaping exception hits the thread's `UncaughtExceptionHandler`), an abandoned CompletableFuture has no such safety net. ## Subtle variants - **`exceptionally` placement.** `exceptionally` only catches failures from stages *above* it. If a *later* stage throws, an earlier `exceptionally` won't see it. Put recovery where it can observe the failures you care about, or use `handle` at the end. - **`whenComplete` doesn't recover.** `whenComplete` lets you *observe* (e.g. log) but the future still completes with the original outcome — if it was a failure, downstream still fails. Use `handle`/`exceptionally` to actually *recover*. - **A handler that itself throws** produces a new exceptional completion, which can again be swallowed if not consumed. - **Aggregates.** `CompletableFuture.allOf(a, b, c)` completes exceptionally if *any* input failed; but you only learn this by joining the `allOf` result. The individual futures still each hold their own outcome. ## Practices that guarantee observation 1. **Always terminate the chain.** Either `join()` it (let the exception propagate to a caller who handles it) or attach a final `exceptionally`/`handle` that logs or recovers. 2. **Log at the boundary.** A trailing `.whenComplete((v, ex) -> { if (ex != null) log.error("task failed", ex); })` ensures every failure is at least recorded. 3. **Don't fire-and-forget without a handler.** If you must not block, still attach an error handler before discarding the reference. 4. **For batches, join the `allOf`** (or stream + handle each) so no member's failure is dropped. 5. **Unwrap correctly.** When you do catch, the throwable is wrapped (`CompletionException`/`ExecutionException`); inspect `getCause()` for the real error. ## Mental model A CompletableFuture failure is *latent*: it exists but is invisible until consumed. "Consume every future" — by joining or handling — is the discipline that converts latent failures into visible ones.