skip to content

How does reduce behave on an empty stream across its three forms, and how should you handle the Optional result?

level: juniorimportance: should knowfreq 45%

answer

  1. 1-arg empty -> Optional.empty()
  2. 2/3-arg empty -> identity returned
  3. get() on empty throws NoSuchElementException
  4. orElse / orElseGet / ifPresent / map
  5. Optional vs identity = design choice

basics

~20 s

On an empty stream the one-arg reduce returns an empty Optional, while the two-arg and three-arg forms return the identity you gave. For the Optional, don't call get() blindly — use orElse, orElseGet, ifPresent, or map so an empty result is handled safely.

solid answer

~40 s

Empty-stream behavior depends on the form. The one-arg reduce(BinaryOperator) has no seed, so an empty stream yields Optional.empty() — there is simply no value to return. The two-arg reduce(identity, accumulator) and three-arg reduce(identity, accumulator, combiner) always return at least the identity, so on an empty stream they return that identity (e.g. 0 for a sum). Handle the one-arg form's Optional<T> deliberately: prefer orElse(default) or orElseGet(supplier) for a fallback value, ifPresent/ifPresentOrElse for side effects, or map/filter to keep working in the Optional. Avoid calling get() without checking isPresent(), since get() on an empty Optional throws NoSuchElementException. The choice between the Optional-returning form and the identity form is really a design choice: do you want 'no elements' to be distinguishable (Optional) or to collapse into a default (identity)?

code

java · 13 lines
java
List<Integer> empty = List.of();

// One-arg: Optional on empty
Optional<Integer> maxOpt = empty.stream().reduce(Integer::max); // Optional.empty
int safeMax = empty.stream().reduce(Integer::max).orElse(-1);   // -1
empty.stream().reduce(Integer::max)
     .ifPresentOrElse(System.out::println, () -> System.out.println("no data"));

// Two-arg: identity returned on empty
int sum = empty.stream().reduce(0, Integer::sum);               // 0

// ANTI-PATTERN: throws NoSuchElementException on empty
// int boom = empty.stream().reduce(Integer::max).get();

go deeper

for a junior

Knows the one-arg form gives an Optional and the seeded forms give the identity on empty, and that you should use orElse rather than get().

for a middle

Explains why only the one-arg form returns Optional, and uses the right combinator (orElse/orElseGet/ifPresent/map) for each situation.

for a senior

Frames the choice between Optional and identity as a domain-modeling decision and distinguishes orElse vs orElseGet evaluation semantics.

for a principal

Advises team conventions for representing 'no result' (Optional vs sentinel/identity), avoiding Optional misuse (fields/params), and the readability/performance trade-offs across an API surface.

## The empty-stream question An **empty stream** has zero elements. What a reduction returns then depends on whether it has a **seed** (identity) to fall back on. ## Form by form - **One-arg `Optional<T> reduce(BinaryOperator<T>)`:** no identity. The reduction would normally start from the first element, but there is no first element. So it returns **`Optional.empty()`**. `Optional<T>` is a container that is either *present* (holds a value) or *empty*; it exists precisely to make 'no result' explicit instead of returning `null`. - **Two-arg `T reduce(T identity, BinaryOperator<T>)`:** there is always the identity. An empty stream simply returns the **identity** unchanged (e.g. `reduce(0, Integer::sum)` over an empty stream returns `0`). - **Three-arg `U reduce(U identity, BiFunction, BinaryOperator)`:** same as two-arg — returns the **identity** on empty. This is why only the one-arg form returns `Optional`: it's the only form without a guaranteed value. ## Handling the Optional safely `Optional<T>` offers safe accessors so you never have to risk a null or an exception: - **`orElse(default)`** — return the value if present, else `default`. The default is always evaluated. - **`orElseGet(supplier)`** — like `orElse` but the supplier runs only if empty (lazy; use when the default is expensive to compute). - **`orElseThrow()` / `orElseThrow(supplier)`** — return the value or throw (a `NoSuchElementException`, or your own exception). - **`ifPresent(consumer)` / `ifPresentOrElse(consumer, runnable)`** — run a side effect only when present (or an alternative when empty). - **`map(fn)` / `filter(pred)` / `flatMap(fn)`** — keep transforming inside the Optional without unwrapping. - **`isPresent()` / `isEmpty()`** — boolean checks (use sparingly; prefer the combinators above). ### The anti-pattern ```java int x = stream.reduce(Integer::max).get(); // throws NoSuchElementException if empty! ``` Calling **`get()`** (or `orElseThrow()`) on an empty Optional throws `NoSuchElementException`. Only call `get()` when you've proven presence, and even then prefer `orElseThrow` for clarity. The whole point of the Optional return is to force you to consider the empty case. ## Which form to choose It's a semantic decision: - If **'no elements' is meaningfully different** from any real result (e.g. 'no transactions yet' vs 'balance is 0'), use the **one-arg form** and keep the `Optional` to preserve that distinction. - If a **sensible default collapses the empty case** (an empty sum *is* 0, an empty count *is* 0), use the **two-/three-arg form** with that default as the identity and get a plain value. ## Example ```java List<Integer> data = List.of(); int max = data.stream().reduce(Integer::max).orElse(-1); // -1, handled safely int sum = data.stream().reduce(0, Integer::sum); // 0, identity returned ```

  • What's the difference between orElse and orElseGet for handling the empty result?
    Both supply a fallback when the Optional is empty, but orElse(default) always evaluates its argument (even when a value is present), while orElseGet(supplier) only invokes the supplier when empty. Use orElseGet when computing the default is expensive or has side effects.
  • If an empty sum should be 0, which reduce form is cleaner?
    The two-arg form reduce(0, Integer::sum): it returns the identity 0 on an empty stream, giving a plain int with no Optional to unwrap. Use the one-arg Optional form only when 'no elements' must be distinguishable from a real 0.

The one-arg reduce is like asking 'who is the tallest person in this empty room?' — there's no answer, so you get an 'empty box' (Optional) rather than a wrong name. The two-arg reduce is like a cash register that starts at 0: even with no sales the total is a perfectly valid 0.

saying these in an interview costs you the question

  • Calling get() on the one-arg reduce result without checking for emptiness.
  • Believing the two-arg form can return an empty Optional (it returns the identity).
  • Returning null instead of using Optional's combinators.
  • Using orElse with an expensive default when orElseGet would avoid the work.

context

resolving links…