Completablefuture`<t>` class: join() vs get()

java

async-programming

exception-handling

best-practices

byAnton Shumikhin·Feb 2, 2025

Select CompletableFuture.join() for efficiency, when you prefer to dodge handling checked exceptions as it throws an unchecked CompletionException. A future.join() statement helps to keep your lambdas and streams clean.

Conversely, use CompletableFuture.get() for a managed exception handling strategy, it throws a checked ExecutionException and InterruptedException, demanding you to explicitly handle these exceptions.

String resultJoin = CompletableFuture.supplyAsync(() -> {/* 👀 Look mom, no hands! */ return "Result";}).join(); // Unchecked exceptions

String resultGet; // Checked exceptions
try {
  resultGet = CompletableFuture.supplyAsync(() -> {/* 🎓 The scholar's choice */ return "Result";}).get();
} catch (ExecutionException | InterruptedException e) {
  throw new RuntimeException(e); // 🎾 We return here!
}

join() vs get(): Trade-Offs Based On Design Choices

When you're at crossroads between using join() or get(), weigh out the implications of each method. join() lends you simplicity of use, while get(), although less streamlined, offers you flexibility with its ability to be interrupted and regulate timed waits.

Interruptibility, Timed Waits and Life Choices:

get() lets your code take a breather before retrying via overloads like get(long timeout, TimeUnit unit).
get() can be stopped short, useful for the real-world where threads need to be freed for other duties.

Exception Handling: Life's Unpredictability Handled

exceptionally() teams up with join(), fostering readable asynchronous code while handling exceptions in a functional style.
Exception handling via get() can feel verbose but it’s thorough - useful when you need to pick apart the cause of your headaches.

Approach and Code Styles - Or How to Win Friends and Influence Computers

While join() and get() are effectively two sides of the same coin, their differential behaviour and exception handling bring out unique characteristics in practice.

In Favor of join(): The Charmed Life

Chain multiple futures without fearing about propagating exceptions, making join() a staple for such cases.
Use join() for concise code, particularly within lambda expressions or method reference usages.

Sticking With get(): The Old Guard

Dissect the cause of failures according to the type of exceptions (ExecutionException vs InterruptedException).
get() fits well in legacy code ecosystems where altering exception handling would instigate extensive refactoring.

Advanced Exception Handling: Going Beyond the Usual

Looking past exceptionally(), CompletableFuture broadens your horizons for dealing with exceptions via handle() which grants you both the result and the exception. With whenComplete(), you can implement actions irrespective of future outcomes, hence making its exception handling phase granular and controllable.

join() or get() - Who Wears the Crown?

Neither method holds a performance crown, it's your responsibility to choose wisely. Coupled with the reality that a CancellationException could be thrown by either, the choice of one over another fundamentally zeroes on readability, maintainability, and the specifics of the application.

Picking the Right Tool for the Job:

For clean, non-blocking code, the modern join() trumps get().
When robustness and detailed control take priority, get() is your knight in shining armor.
Irrespective of your choice, consistency is key for easier debugging and maintaining team sanity.

explain-codes / Java / Completablefuture<t> class: join() vs get()

Linked

What does this thread join code mean?



Implements Closeable or implements AutoCloseable



What is the fastest way to send 100,000 HTTP requests in Python?



Why do we need the "finally" clause in Python?



Timeout on a function call

