Using Java 8 Optional to Avoid NullPointerException

NullPointerException (NPE) is a common issue in Java development; the article starts with a simple example that throws NPE when user.getAddress().getProvince(); is executed while user is null. The traditional solution uses nested if checks, which quickly becomes unreadable.

Java 8 introduces the Optional class to make such null‑handling more elegant. The API includes constructors ( Optional(T value) – private), factory methods ( of(T value), ofNullable(T value), empty()), and several terminal operations.

Factory methods : of(T value) creates an Optional and throws NPE if the argument is null; ofNullable(T value) returns EMPTY when the argument is null; empty() returns a shared empty instance.

Value extraction : orElse(T other) returns the contained value or a default; orElseGet(Supplier<? extends T> supplier) lazily supplies a default; orElseThrow(Supplier<? extends Throwable> supplier) throws the supplied exception when the value is absent.

Transformation : map(Function<? super T, ? extends U> mapper) applies a function to the value and wraps the result in an Optional; flatMap(Function<? super T, Optional<U>> mapper) is similar but expects the mapper to return an Optional directly.

Presence checks : isPresent() returns true if a value exists; ifPresent(Consumer<? super T> consumer) executes the consumer only when the value is present.

Filtering : filter(Predicate<? super T> predicate) keeps the value only if it matches the predicate, otherwise returns EMPTY. Example:

Optional.ofNullable(user).filter(u -> u.getName().length() < 6)

.

The article then shows practical refactorings: replacing multi‑level null checks in a getCity(User user) method with a fluent chain

Optional.ofNullable(user).map(u -> u.getAddress()).map(a -> a.getCity()).orElseThrow(() -> new Exception("取指错误"))

, simplifying conditional execution with Optional.ofNullable(user).ifPresent(u -> dosomething(u)), and condensing object creation logic using filter and orElseGet.

While the Optional‑based style makes code more concise, the author warns that excessive chaining can reduce readability and should be used judiciously in real projects.