Kotlin Void, Unit, Nothing : Guide complet 2025

Kotlin - Void vs. Unit vs. Nothing : meilleures pratiques en 2025

Bonjour, collègues ! Si vous avez déjà écrit en Kotlin et vous êtes demandé : "Mais pourquoi ici c'est Unit, et pas void ? Et qu'est-ce que cette bête appelée Nothing ?" — vous êtes au bon endroit. Ce sujet est un véritable succès sur Stack Overflow avec des milliers de vues, et ce n'est pas pour rien. La confusion entre Void, Unit et Nothing peut dérouter même un développeur expérimenté. En 2025, alors que Kotlin occupe solidement sa place dans le backend (Ktor, Spring) et Android, comprendre ces types n'est pas un simple caprice, mais une nécessité pour écrire un code propre, sûr et expressif.

Dans cet article, nous ne nous contenterons pas d'énumérer les définitions. Nous les analyserons avec des exemples concrets, montrerons où chacun est approprié, et où il s'agit d'un péché mortel. C'est parti !

Bref résumé : qu'est-ce que quoi ?

Mettons immédiatement les points sur les i. Ces trois types résolvent des problèmes différents, bien qu'ils semblent similaires à première vue.

\n
• Void — c'est une relique de Java. En Kotlin, il n'existe que pour la compatibilité. Ne l'utilisez jamais dans du code Kotlin pur.
\n
• Unit — c'est "je ne retourne rien, mais je suis quand même un type". L'analogue de void en Java, mais en mieux. Utilisé dans 99% des cas où une fonction ne retourne pas de résultat significatif.
\n
• Nothing — c'est "la fonction ne se terminera jamais normalement". Elle va soit lever une exception, soit entrer dans une boucle infinie. C'est un outil puissant pour le contrôle du flux d'exécution.
\n

Cela semble simple ? Creusons plus profondément.

Void — l'étranger parmi les siens

Si vous écrivez en Kotlin pur, oubliez Void comme un mauvais rêve. C'est une classe de Java (java.lang.Void), qui est un wrapper pour le mot-clé void. Il existe en Kotlin uniquement pour l'interopérabilité avec le code Java.

Exemple où Void peut apparaître dans votre projet :

import java.lang.Void\n\n// Ne faites jamais cela en Kotlin pur !\nfun doSomething(): Void? {\n    println("Je fais quelque chose...")\n    return null // Il est obligatoire de retourner null, sinon erreur de compilation\n}

Vous voyez ce return null ? C'est le principal inconvénient. Void est un type dont on ne peut pas créer d'instance (son constructeur est privé), mais il peut être null. Cela crée de la confusion et du code superflu.

Meilleure pratique 2025 : N'utilisez Void que si vous redéfinissez une méthode d'une bibliothèque Java qui exige Void comme paramètre générique. Par exemple, dans Callable<Void>. Dans tous les autres cas — utilisez Unit.

Unit — le roi des fonctions vides

Unit est la véritable manière Kotlin de dire : "La fonction est exécutée, mais le résultat ne m'intéresse pas". Contrairement à void, Unit est un type à part entière avec une seule valeur possible — Unit.

Cela offre des possibilités intéressantes :

\n
1. Les génériques. Vous pouvez utiliser Unit dans des fonctions génériques.
\n
2. Les fonctions d'ordre supérieur. Vous pouvez passer une fonction qui retourne Unit comme argument.
\n
3. Les extensions. Vous pouvez écrire des fonctions d'extension qui retournent Unit.
\n

Exemple standard — les expressions lambda :

fun executeAction(action: () -> Unit) {\n    println("Préparation de l'action...")\n    action() // Appel de la fonction passée\n    println("Action exécutée.")\n}\n\nfun main() {\n    // Lambda qui ne retourne rien, mais produit un effet de bord\n    executeAction {\n        println("Bonjour depuis la lambda !")\n    }\n}

Ici