Null Safety en Kotlin: El Fin de la 'One Billion Dollar Mistake'

💥 Teoría: El Error de los Mil Millones de Dólares

Tony Hoare, el inventor de la referencia nula (null reference) en 1965, lo llamó “mi error de los mil millones de dólares”. En Java (y C++, C#), cualquier objeto puede ser null, lo que lleva a la temida NullPointerException (NPE) en runtime.

Kotlin resuelve esto moviendo el problema del Runtime al Compile time.

El Sistema de Tipos Dual

En Kotlin, la jerarquía de tipos se duplica.

• String: NUNCA puede ser nulo.
• String?: PUEDE ser nulo.

String es un subtipo de Any. String? es un subtipo de Any?.

Lo genial es que String es subtipo de String?. Puedes pasar un String donde se espera String?, pero no al revés.

🛠️ Herramientas de Null Safety

1. Safe Call (?.)

La herramienta más usada. Si es nulo, no hace nada y devuelve null.

val length: Int? = maybeNullString?.length

Nótese que el resultado es Int? (nullable), porque si maybeNullString es null, length será null.

2. Elvis Operator (?:)

Provee un valor por defecto si algo es null.

val length: Int = maybeNullString?.length ?: 0

Ahora el resultado es Int (no-nullable). Es como un if-else en una línea.

Truco Avanzado: throw y return son expresiones en Kotlin, así que puedes usarlas con Elvis.

val user = repository.findUser(id) ?: throw UserNotFoundException(id)
val parent = view.parent ?: return

3. Not-Null Assertion (!!)

“Sé lo que estoy haciendo, confía en mí”. Lanza NPE si es nulo.

Regla de Oro: Evítalo. Si ves !! en un Code Review, pide una justificación muy buena. Casi siempre hay una mejor forma (?: o requireNotNull).

4. Safe Cast (as?)

Intenta castear, devuelve null si falla.

val fragment = view as? UserFragment
// fragment es UserFragment?

🧠 Técnicas Avanzadas

1. let para bloques seguros

Si tienes una variable mutable nullable, Kotlin no te deja hacer smart cast porque podría haber cambiado por otro hilo.

var user: User? = ...

if (user != null) {
    // user.name // Error: Smart cast impossible
}

// Solución: Captura inmutable con let
user?.let { safeUser ->
    print(safeUser.name)
}

2. Extension Functions sobre Tipos Nullables

Puedes definir funciones que acepten null como receptor.

fun String?.isNullOrEmpty(): Boolean {
    return this == null || this.isEmpty()
}

// Uso (no necesito ?. safe call)
val s: String? = null
if (s.isNullOrEmpty()) { ... }

3. Interoperabilidad con Java (Platform Types)

Cuando llamas a Java desde Kotlin, los tipos son String! (Platform Type). Kotlin no sabe si es nullable o no.

• Puedes tratarlo como String (riesgo de NPE).
• Puedes tratarlo como String? (seguro).

Mejor práctica: Siempre anota tu código Java con @Nullable y @NonNull para que Kotlin sepa qué hacer.

🎯 Conclusión

El Null Safety de Kotlin no es solo azúcar sintáctico; es una característica fundamental de diseño que obliga a pensar en la “nulabilidad” como parte del contrato de tu API. Al adoptar estos patrones, eliminas una categoría entera de bugs de tu aplicación.