Java Optional: cómo evitar null y NullPointerException

El problema que resuelve Optional

Un método que quizá no tenga una respuesta siempre ha tenido una opción incómoda en Java: devolver null y confiar en que quien lo llama recuerde comprobarlo. Normalmente no lo hace, y el resultado es un NullPointerException que aparece muy lejos del método que devolvió el null.

Optional<T> es una pequeña caja que o bien contiene un valor o bien está explícitamente vacía. Al devolver Optional<User> en lugar de User, un método les dice a quienes lo llaman "esto podría no encontrar nada" en su propia firma, y el compilador los guía hacia manejar ese caso.

import java.util.Optional;

public class Main {
    public static void main(String[] args) {
        Optional<String> found = Optional.of("Ada");
        Optional<String> missing = Optional.empty();

        System.out.println(found.isPresent());   // true
        System.out.println(missing.isPresent());  // false
    }
}

Crear un Optional

Hay tres métodos de fábrica, y elegir el correcto importa:

• Optional.of(value): el valor debe ser no nulo, o lanza NullPointerException en el acto.
• Optional.ofNullable(value): vacío si el valor es null, presente en caso contrario. Úsalo para envolver algo que podría ser null.
• Optional.empty(): un optional vacío.

import java.util.Optional;

public class Main {
    public static void main(String[] args) {
        String maybeNull = System.getenv("DOES_NOT_EXIST");  // devuelve null

        Optional<String> safe = Optional.ofNullable(maybeNull);
        System.out.println(safe.isPresent());  // false, sin excepción

        // Optional.of(maybeNull) lanzaría NullPointerException aquí
        Optional<String> sure = Optional.of("definitely here");
        System.out.println(sure.isPresent());  // true
    }
}

Un error común es recurrir a Optional.of(x) sobre un valor que podría ser null: eso anula su propósito y lanza justo la excepción que intentabas evitar. Ante la duda, usa ofNullable.

Leer el valor de forma segura

Una vez que tienes un optional, el objetivo es sacar el valor sin dar por hecho que está ahí. La herramienta brusca es get(), y casi nunca deberías usarla:

Optional<String> name = Optional.empty();
String value = name.get();   // lanza NoSuchElementException - un NPE disfrazado

En su lugar, proporciona un valor de respaldo o reacciona a la presencia. orElse devuelve un valor por defecto cuando está vacío; ifPresent ejecuta código solo cuando existe un valor:

import java.util.Optional;

public class Main {
    public static void main(String[] args) {
        Optional<String> name = Optional.of("Grace");
        Optional<String> blank = Optional.empty();

        System.out.println(name.orElse("anonymous"));   // Grace
        System.out.println(blank.orElse("anonymous"));  // anonymous

        name.ifPresent(n -> System.out.println("Hello, " + n));
        blank.ifPresent(n -> System.out.println("never prints"));
    }
}

Usa orElseGet(supplier) en lugar de orElse cuando el valor por defecto sea costoso de construir: el supplier solo se ejecuta si el optional está realmente vacío. El argumento de orElse siempre se evalúa, incluso cuando no hace falta.

orElseThrow para "esto debería existir"

A veces el vacío sí es un error: un valor de configuración obligatorio, un usuario que debería estar en la base de datos. orElseThrow convierte un optional vacío en una excepción clara que tú eliges:

import java.util.Optional;

public class Main {
    static Optional<Integer> parsePort(String raw) {
        try {
            return Optional.of(Integer.parseInt(raw));
        } catch (NumberFormatException e) {
            return Optional.empty();
        }
    }

    public static void main(String[] args) {
        int port = parsePort("8080")
            .orElseThrow(() -> new IllegalStateException("port must be a number"));
        System.out.println("listening on " + port);

        try {
            parsePort("nope")
                .orElseThrow(() -> new IllegalStateException("port must be a number"));
        } catch (IllegalStateException e) {
            System.out.println("caught: " + e.getMessage());
        }
    }
}

Esto se lee mucho mejor que un bloque if (opt.isPresent()) y hace explícito el fallo justo en el punto donde ocurre.

Transformar con map y filter

La verdadera recompensa es el encadenamiento. map aplica una función al valor solo si está presente y deja vacío un optional vacío, así que transformas sin tocar nunca un null. filter descarta el valor si no supera una prueba.

import java.util.Optional;

public class Main {
    public static void main(String[] args) {
        Optional<String> raw = Optional.of("  Coddy  ");

        String result = raw
            .map(String::trim)          // "Coddy"
            .filter(s -> !s.isEmpty())  // conserva solo lo no vacío
            .map(String::toUpperCase)   // "CODDY"
            .orElse("EMPTY");

        System.out.println(result);  // CODDY

        // Un optional vacío fluye intacto - sin NPE, sin ramas
        String none = Optional.<String>empty()
            .map(String::trim)
            .orElse("EMPTY");
        System.out.println(none);    // EMPTY
    }
}

Si tu función de mapeo devuelve a su vez un Optional, usa flatMap en lugar de map para evitar un incómodo Optional<Optional<T>>. Esto refleja la distinción map/flatMap que viste con los streams: un Optional se comporta de forma muy parecida a un stream de cero o un elemento.

Dónde encaja Optional (y dónde no)

Optional está diseñado como tipo de retorno para métodos que legítimamente pueden no producir un resultado: los ejemplos canónicos son Stream.findFirst(), las búsquedas estilo Map y el parseo. Úsalo ahí y tu API documenta sus propios huecos.

No está pensado para:

• Campos. No es serializable y añade un objeto por campo. Usa referencias normales y valida en el constructor.
• Parámetros de método. Quien llama tiene entonces que envolver los argumentos en Optional.of(...), lo cual es más ruidoso que una sobrecarga o un parámetro que admita null.
• Colecciones. Devuelve una List vacía, no un Optional<List>. Una colección vacía ya significa "nada".

Tratado como tipo de retorno, Optional convierte los errores silenciosos de null en avisos en tiempo de compilación para manejar el caso ausente.

Siguiente: Excepciones

Optional maneja con limpieza el caso cotidiano de "puede que no haya valor", pero algunos fallos son genuinamente excepcionales: un archivo que no se abre, una red que se cae, una entrada que no se puede parsear. Java modela esos casos con excepciones, y esa es la siguiente página.