Kotlin Void, Unit, Nothing: Das vollständige Handbuch 2025

Kotlin - Void vs. Unit vs. Nothing: Best Practices im Jahr 2025

Hallo Kollegen! Wenn Sie jemals in Kotlin programmiert und sich gefragt haben: "Warum steht hier Unit und nicht void? Und was ist das für ein Wesen, Nothing?" — dann sind Sie hier genau richtig. Dieses Thema ist ein echter Hit auf Stack Overflow mit tausenden Aufrufen, und das zu Recht. Die Verwirrung zwischen Void, Unit und Nothing kann selbst erfahrene Entwickler aus dem Konzept bringen. Im Jahr 2025, in dem Kotlin sich fest im Backend-Bereich (Ktor, Spring) und bei Android etabliert hat, ist das Verständnis dieser Typen keine bloße Marotte, sondern eine Notwendigkeit für sauberen, sicheren und ausdrucksstarken Code.

In diesem Artikel werden wir nicht einfach nur Definitionen auflisten. Wir werden sie anhand realer Beispiele analysieren und zeigen, wo jeder von ihnen angebracht ist und wo er eine Todsünde darstellt. Los geht's!

Kurz und knapp: Was ist was?

Lassen Sie uns gleich Klarheit schaffen. Diese drei Typen lösen unterschiedliche Aufgaben, auch wenn sie auf den ersten Blick ähnlich erscheinen.

\n
• Void — ist ein Überbleibsel aus Java. In Kotlin existiert es nur aus Kompatibilitätsgründen. Verwenden Sie es niemals in reinem Kotlin-Code.
\n
• Unit — bedeutet "Ich gebe nichts zurück, aber ich bin trotzdem ein Typ". Das Analogon zu void in Java, aber besser. Wird in 99% der Fälle verwendet, wenn eine Funktion kein signifikantes Ergebnis zurückgibt.
\n
• Nothing — bedeutet "Die Funktion wird niemals normal beendet". Sie wirft entweder eine Ausnahme oder läuft in eine Endlosschleife. Es ist ein mächtiges Werkzeug zur Steuerung des Ausführungsflusses.
\n

Klingt einfach? Dann tauchen wir tiefer ein.

Void — ein Fremder unter sich

Wenn Sie in reinem Kotlin programmieren, vergessen Sie Void wie einen bösen Traum. Es ist eine Klasse aus Java (java.lang.Void), die einen Wrapper für das Schlüsselwort void darstellt. Sie existiert in Kotlin ausschließlich für die Interoperabilität mit Java-Code.

Ein Beispiel, wann Void in Ihrem Projekt auftauchen könnte:

import java.lang.Void\n\n// Machen Sie das niemals in reinem Kotlin!\nfun doSomething(): Void? {\n    println("Mache etwas...")\n    return null // Es muss zwingend null zurückgegeben werden, sonst Kompilierungsfehler\n}

Sehen Sie dieses return null? Das ist der Hauptnachteil. Void ist ein Typ, von dem keine Instanz erstellt werden kann (er hat einen privaten Konstruktor), aber er kann null sein. Das führt zu Verwirrung und überflüssigem Code.

Best Practice 2025: Verwenden Sie Void nur, wenn Sie eine Methode aus einer Java-Bibliothek überschreiben, die Void als generischen Parameter erfordert. Zum Beispiel in Callable<Void>. In allen anderen Fällen verwenden Sie Unit.

Unit — der König der leeren Funktionen

Unit ist die wahre Kotlin-Art zu sagen: "Die Funktion wurde ausgeführt, aber das Ergebnis interessiert mich nicht". Im Gegensatz zu void ist Unit ein vollwertiger Typ mit einem einzigen Wert — Unit.

Das bietet großartige Möglichkeiten:

\n
1. Generics. Sie können Unit in generischen Funktionen verwenden.
\n
2. Funktionen höherer Ordnung. Sie können eine Funktion, die Unit zurückgibt, als Argument übergeben.
\n
3. Erweiterungen. Sie können Erweiterungsfunktionen schreiben, die Unit zurückgeben.
\n

Ein Standardbeispiel sind Lambda-Ausdrücke:

fun executeAction(action: () -> Unit) {\n    println("Bereite Aktion vor...")\n    action() // Ruft die übergebene Funktion auf\n    println("Aktion ausgeführt.")\n}\n\nfun main() {\n    // Lambda, die nichts zurückgibt, aber einen Seiteneffekt erzeugt\n    executeAction {\n        println("Hallo aus dem Lambda!")\n    }\n}

Hier