Null-Sicherheit in Kotlin – ?., ?: und warum du !! meiden solltest
Kotlins Typsystem trennt nullbare von nicht-nullbaren Werten – die NullPointerException wird damit fast unmöglich. Ich zeige dir die drei Operatoren, die du täglich brauchst, und die eine Falle namens !!.
Die „Milliarden-Dollar-Fehler" – die NullPointerException – hat Kotlin fast abgeschafft. Der Trick: Ein String kann nie null sein, nur ein String? (mit Fragezeichen) darf es. Der Compiler zwingt dich, den Fall zu behandeln.
Safe Call und Elvis
val name: String? = user.nickname
// ?. → ruf nur auf, wenn nicht null (sonst ist das Ergebnis null)
val length: Int? = name?.length
// ?: (Elvis) → nimm den rechten Wert, wenn links null ist
val shown: String = name ?: "Gast"
// Beides zusammen – die Alltagszeile schlechthin:
val len: Int = user.nickname?.trim()?.length ?: 0?. bricht die Kette sauber ab, sobald etwas null ist. ?: liefert den Ersatzwert. Damit deckst du 90 % aller Fälle ab.
Nur ausführen, wenn nicht null
user.email?.let { adresse ->
sendMail(adresse) // läuft nur, wenn email != null
}Die Falle: !!
val len = name!!.length // wirft NPE, wenn name doch null istDer Doppel-Ausruf !! sagt „ich weiß es besser, das ist niemals null" – und genau da kommt die NPE zurück, die Kotlin eigentlich verhindern wollte. Nutze !! fast nie. Willst du wirklich hart abbrechen, ist requireNotNull(name) { "name fehlt" } besser: gleiche Wirkung, aber mit klarer Fehlermeldung.
Sauberer Umgang mit null erspart mir in jeder App eine ganze Klasse von Abstürzen. Mehr davon auf code.bymw.de.
Quellen
Du brauchst mehr als ein Snippet?
Ich entwickle Android-Apps in Kotlin und moderne Websites für Selbstständige und kleine Unternehmen — von der ersten Idee bis zum Release.
Projekt anfragen →Verwandte Snippets
Nach mehreren Kriterien sortieren – sortedWith, compareBy und thenBy
Erst nach Priorität, dann nach Datum, und die ohne Termin ganz nach hinten: Solche Sortierungen werden mit einem handgeschriebenen Comparator schnell unleserlich. Kotlin hat dafür eine Baukastenschreibweise.
Room-Migrationen – das Schema ändern, ohne Nutzerdaten zu verlieren
Eine neue Spalte in der Entity, und beim nächsten Start ist der Spielstand weg – weil fallbackToDestructiveMigration die Datenbank einfach löscht. So machst du es richtig, inklusive Test.
Fehler in Coroutinen – coroutineScope, supervisorScope und wer wen mitreißt
Eine von fünf parallelen Abfragen scheitert – und plötzlich sind alle abgebrochen. Das ist kein Bug, sondern strukturierte Nebenläufigkeit. Wer den Unterschied zwischen coroutineScope und supervisorScope kennt, steuert das bewusst.