NoSuchElementException: Fix Empty Access Fast

The stack trace says NoSuchElementException at line 87, which reads queue.next(). The queue had items a moment ago — you watched them go in. So where did they go? Somewhere between insertion and line 87, something consumed the last element, or the loop ran one iteration too many, or the Optional you assumed was full arrived empty from a lookup that missed. This exception never lies: at that exact line, there was nothing left to take.

It's also the shape-shifter of Java errors. The same exception comes from iterators, scanners, optionals, queues, and tokenizers — five APIs with five different guard methods. Developers learn one guard and apply it everywhere, which is how hasNext checks end up beside Optional.get calls they can't protect.

This guide maps each source to its guard. You'll learn the iterator and scanner patterns, why Optional.get deserves its reputation, how streams should terminate, and the queue and stack variants most guides skip. By the end, every take from a possibly-empty holder gets a check first, and this exception becomes a test assertion instead of a production surprise.

Iterator.next Without hasNext: the Original Shape

The Iterator contract is a two-step dance: hasNext asks, next takes. Calling next without asking throws NoSuchElementException the moment the iterator is exhausted — usually on the final loop iteration that overshoots by one. Manual while loops with iterators are the prime suspects, especially ones where the hasNext check guards a different take than the one that throws, or where elements get removed mid-loop and the count shifts under the check.

Enhanced for-loops eliminate this class entirely for simple traversal because the compiler writes the hasNext/next pair correctly every time. Prefer for (String s : list) over manual iterator code unless you need removal during traversal — and for removal, Iterator.remove() is the sanctioned path, covered in the concurrent-modification guide. When you must use an iterator explicitly, keep the hasNext and next calls adjacent so no edit can separate the guard from its take.

The snippet shows both shapes: the fragile manual loop and the robust alternatives. Copy the adjacent-guard pattern whenever explicit iterators are unavoidable, and treat any next() without a hasNext on the same screen as a review finding. Treat any next call without a hasNext on the same screen as a defect during review, even when tests currently pass. Copy the adjacent-guard pattern whenever explicit iterators are unavoidable in your codebase.

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

public final class IteratorGuards {
    public static void fragile(List<String> items) {
        Iterator<String> it = items.iterator();
        while (true) { // overshoots: throws on the last take
            System.out.println(it.next());
        }
    }

    public static void guarded(List<String> items) {
        Iterator<String> it = items.iterator();
        while (it.hasNext()) { // guard and take stay adjacent
            System.out.println(it.next());
        }
    }

    public static void preferred(List<String> items) {
        for (String s : items) { // compiler writes the pair for you
            System.out.println(s);
        }
    }

    public static void main(String[] args) {
        guarded(new ArrayList<>(List.of("a", "b")));
    }
}

Scanner Past End of Input and the nextLine Trap

Scanner throws NoSuchElementException when reads outrun input: nextLine() on a short file, nextInt() with no tokens left, or next() after the stream ended. File-processing loops that assume a fixed shape are the usual victims — a 99-line file fed to a loop expecting 100, or a trailing blank line that isn't actually there. Guard every read loop with hasNextLine() or hasNext() so short input ends the loop instead of throwing.

The sneakier variant mixes nextInt() with nextLine(). nextInt consumes digits but leaves the newline, so the following nextLine reads that leftover empty line instead of the next real line. Every subsequent read shifts by one, and the final read runs off the end and throws. The fix is a debris-consuming nextLine() after each numeric read, or reading everything with nextLine and parsing with Integer.parseInt — which also gives better error messages.

Always close scanners over files with try-with-resources so a throw doesn't leak handles. The snippet shows the guarded file loop plus the debris fix. Test scanners with short, empty, and newline-terminated files — those three inputs catch nearly every scanner bug before production does. Test every scanner with short, empty, and unterminated inputs before shipping; those three catch nearly every scanner bug. Always close file scanners with try-with-resources so a throw cannot leak handles.

import java.io.IOException;
import java.nio.file.Path;
import java.util.Scanner;

public final class ScanSafe {
    public static void dumpLines(Path file) throws IOException {
        try (Scanner sc = new Scanner(file)) {
            while (sc.hasNextLine()) { // short files end cleanly
                System.out.println(sc.nextLine());
            }
        }
    }

    public static void readPairs(Scanner sc) {
        while (sc.hasNextInt()) {
            int id = sc.nextInt();
            sc.nextLine(); // consume leftover newline debris
            String name = sc.hasNextLine() ? sc.nextLine() : "";
            System.out.println(id + "=" + name);
        }
    }
}

Optional.get on Empty: the Costliest One-Liner

Optional.get() on an empty Optional throws NoSuchElementException, and it's the most expensive instance because the crash lands far from the lookup that missed. A repository returns empty, the value flows through two clean layers, then .get() explodes in a place with no hint about which lookup failed. The stack trace shows the grab, never the miss — so debugging starts blind unless the code logs keys.

The replacement depends on what empty means. A sensible default exists: orElse or orElseGet, with the lazy supplier for expensive defaults. Empty is a bug that needs a loud message: orElseThrow(() -> new IllegalStateException("missing plan for " + code)). Empty is a normal branch: ifPresent, map, or filter chains that skip gracefully. What never belongs in reviewed code is a bare .get() — grep for it in CI and fail the build, because each one is a delayed crash.

The snippet contrasts the crashing shape with all three safe replacements. Notice the orElseThrow message carries the lookup key; that single habit turns the next miss from a mystery into a one-line fix. Make key-carrying messages the team standard and Optional stops being scary. Make key-carrying orElseThrow messages the team standard and Optional stops being scary within a sprint. Add a CI grep that fails the build on bare get calls so new ones cannot land unnoticed.

import java.util.Map;
import java.util.Optional;

public final class OptionalSafe {
    private final Map<String, String> plans;

    public OptionalSafe(Map<String, String> plans) { this.plans = plans; }

    public String crash(String code) {
        return Optional.ofNullable(plans.get(code)).get(); // throws when the code misses
    }

    public String withDefault(String code) {
        return Optional.ofNullable(plans.get(code)).orElse("BASIC");
    }

    public String orLoud(String code) {
        return Optional.ofNullable(plans.get(code))
                .orElseThrow(() -> new IllegalStateException("missing plan for code=" + code));
    }

    public void ifPresent(String code) {
        Optional.ofNullable(plans.get(code)).ifPresent(p -> System.out.println("plan=" + p));
    }
}

Stream.findFirst and Friends Done Safely

Streams terminate in Optionals, which surprises developers who expected streams to be the safe modern path. findFirst() and findAny() return Optional, max() and min() return Optional, and reduce() without an identity returns Optional too. Calling .get() on any of them reintroduces the exact crash streams were supposed to avoid — now wearing functional clothes. The terminal must handle empty: orElse, orElseThrow with context, or ifPresent for side effects.

Empty streams are normal, not exceptional. A filter matching nothing, a search over an empty list, a max() of no readings — all legitimately empty. Code that treats them as impossible crashes the first quiet day in production. Write the empty path deliberately: a default reading, a skip with a log line, or a domain exception that names the search criteria. The stream pipeline stays clean; only the terminal branches.

The snippet shows safe terminals for the three common shapes. Note the orElseThrow message includes the search input — same key-carrying habit as Optional, because a stream miss is a lookup miss. Review every .get() chained after a stream terminal the way you'd review a bare Optional.get. Review every get chained after a stream terminal the way you would review a bare Optional.get in plain code. Note the orElseThrow message should include the search input, because a stream miss is a lookup miss.

import java.util.Comparator;
import java.util.List;

public final class StreamTerminals {
    public static String firstLong(List<String> names) {
        return names.stream().filter(s -> s.length() > 5).findFirst().orElse("NONE");
    }

    public static String loudest(List<String> names, String query) {
        return names.stream().filter(s -> s.startsWith(query)).findFirst()
                .orElseThrow(() -> new IllegalStateException("no name starts with '" + query + "'"));
    }

    public static void printMax(List<Integer> readings) {
        readings.stream().max(Comparator.naturalOrder())
                .ifPresent(m -> System.out.println("max=" + m));
    }
}

Queues, Stacks, and Tokenizers: the Rest of the Family

Queue has a split personality you must memorize: remove() and element() throw NoSuchElementException on empty, while poll() and peek() return null instead. In producer-consumer code where emptiness is routine, poll and peek are the correct calls — check the null and move on. Reserve remove and element for places where empty is genuinely impossible, and even there prefer poll plus an explicit guard with a message. ArrayDeque as a stack follows the same split: pop() throws while poll() returns null.

StringTokenizer is legacy but still throws this exception from nextToken() when tokens run out — migrate to String.split or Scanner, and where you can't, guard with hasMoreTokens(). Enumeration.nextElement() is the same story in old APIs. The pattern never changes: every taking method has a checking sibling or a null-returning twin, and the bug is reaching for the throwing one out of habit.

The snippet shows queue draining both ways so the contrast is visible. The poll loop handles concurrent consumers and shutdown races gracefully; the remove loop throws the moment another thread wins the last element. In concurrent code the throwing twin is not just risky — it's wrong. In concurrent code the throwing twin is not just risky, it is wrong, because races make empty routine rather than exceptional. The pattern never changes: pair every taking method with its checking sibling or null-returning twin.

import java.util.ArrayDeque;
import java.util.Queue;

public final class QueueDrain {
    public static void drainSafely(Queue<String> q) {
        String job;
        while ((job = q.poll()) != null) { // null means empty: clean exit
            System.out.println("run " + job);
        }
    }

    public static void stackPop(ArrayDeque<String> stack) {
        String top = stack.poll(); // null-safe twin of pop()
        if (top == null) {
            System.out.println("stack empty, nothing to undo");
            return;
        }
        System.out.println("undo " + top);
    }
}

Reading the Trace to the Empty Source

The stack trace for this exception is short and honest: it names the taking method and line. Your job is walking backward from the take to the source that ran dry. List what feeds that line — which iterator, which scanner, which lookup — then check each feed's size, input, or presence. For iterators, ask what consumed elements before this take; for scanners, check the input length; for Optionals, find the lookup and test it with the failing key.

Modern JDK messages sometimes add which call failed, but don't depend on it — the line number plus your knowledge of the feeds is enough. The fastest technique is a temporary log one line above the take printing sizes and hasNext values; the last log line before the crash names the empty source with zero guesswork. Remove the log after, or better, keep a debug-level version permanently.

Lock the fix with a test that feeds empty input: an empty list through the loop, a missing key through the lookup, an empty file through the scanner. Empty-input tests are cheap and they guard exactly the path that crashed. Every method that takes from a possibly-empty source deserves one. Keep a debug-level size log permanently near tricky takes; the trace shows the grab while the size history shows the cause. Every method that takes from a possibly-empty source deserves an empty-input test.