Kotlin Void, Unit, Nothing: Guía completa 2025

Kotlin - Void vs. Unit vs. Nothing: mejores prácticas en 2025

¡Hola, colegas! Si alguna vez has escrito en Kotlin y te has preguntado: "¿Por qué aquí va Unit y no void? ¿Y qué es esa bestia llamada Nothing?" — has llegado al lugar indicado. Este tema es un verdadero éxito en Stack Overflow con miles de visitas, y no es para menos. La confusión entre Void, Unit y Nothing puede desconcertar incluso a un desarrollador experimentado. En 2025, cuando Kotlin ocupa con confianza un nicho en backend (Ktor, Spring) y Android, comprender estos tipos no es un capricho, sino una necesidad para escribir código limpio, seguro y expresivo.

En este artículo no solo enumeraremos definiciones. Las analizaremos con ejemplos reales, mostraremos dónde es apropiado cada uno y dónde es un pecado mortal. ¡Allá vamos!

Brevemente sobre lo principal: ¿qué es qué?

Aclaremos las cosas de inmediato. Estos tres tipos resuelven problemas diferentes, aunque a simple vista parezcan similares.

\n
• Void — es una reliquia de Java. En Kotlin existe solo por compatibilidad. Nunca lo uses en código Kotlin puro.
\n
• Unit — significa "no devuelvo nada, pero sigo siendo un tipo". Es el análogo de void en Java, pero mejor. Se usa en el 99% de los casos cuando una función no devuelve un resultado significativo.
\n
• Nothing — significa "la función nunca terminará normalmente". O lanzará una excepción o entrará en un bucle infinito. Es una herramienta poderosa para controlar el flujo de ejecución.
\n

¿Suena simple? Profundicemos.

Void — un extraño entre los suyos

Si escribes en Kotlin puro, olvídate de Void como de una pesadilla. Es una clase de Java (java.lang.Void) que es un envoltorio para la palabra clave void. Existe en Kotlin exclusivamente para la interoperabilidad con código Java.

Ejemplo de cuándo Void podría aparecer en tu proyecto:

import java.lang.Void\n\n// ¡Nunca hagas esto en Kotlin puro!\nfun doSomething(): Void? {\n    println("Haciendo algo...")\n    return null // Obligatoriamente hay que devolver null, de lo contrario error de compilación\n}

¿Ves ese return null? Esa es la principal desventaja. Void es un tipo del que no se puede crear una instancia (tiene un constructor privado), pero puede ser null. Esto genera confusión y código innecesario.

Mejor práctica 2025: Usa Void solo si estás sobrescribiendo un método de una biblioteca Java que requiera Void como parámetro genérico. Por ejemplo, en Callable<Void>. En todos los demás casos, usa Unit.

Unit — el rey de las funciones vacías

Unit es la forma genuina de Kotlin de decir: "La función se ejecutó, pero el resultado no me interesa". A diferencia de void, Unit es un tipo completo con un único valor: Unit.

Esto ofrece grandes posibilidades:

\n
1. Genéricos. Puedes usar Unit en funciones genéricas.
\n
2. Funciones de orden superior. Puedes pasar una función que devuelva Unit como argumento.
\n
3. Extensiones. Puedes escribir funciones de extensión que devuelvan Unit.
\n

Un ejemplo estándar son las expresiones lambda:

fun executeAction(action: () -> Unit) {\n    println("Preparándose para la acción...")\n    action() // Llamamos a la función pasada\n    println("Acción completada.")\n}\n\nfun main() {\n    // Lambda que no devuelve nada, pero produce un efecto secundario\n    executeAction {\n        println("¡Hola desde la lambda!")\n    }\n}

Aquí