The CompletionStage interface and CompletableFuture implementation lack some methods for dealing with exceptional outcomes that users need and expect based on presence of related non-exception-handling methods. Requests for these have been posted on concurrency-interest list; for example: http://cs.oswego.edu/pipermail/concurrency-interest/2018-September/016512.html

Addressing these requires methods to cover all variants of exceptionally{Compose}{Async}:

 exceptionally(Function<Throwable, ? extends T> f) // already exists
 exceptionallyAsync(Function<Throwable, ? extends T> f);
 exceptionallyAsync(Function<Throwable, ? extends T> f, Executor e);
 exceptionallyCompose(Function<Throwable, ? extends CompletionStage<T>> f);
 exceptionallyComposeAsync(Function<Throwable, ? extends
CompletionStage<T>> f);
 exceptionallyComposeAsync(Function<Throwable, ? extends
CompletionStage<T>> f, Executor e);

Default implementations in CompletionStage have tolerable overhead; direct implementations in CompletableFuture are more efficient.

We currently have these, as well as tck tests in jsr166 repo.