ProgrammierungKotlin Entwickler

Erläutern Sie die Besonderheiten der Arbeit mit Nullable-Typen in Kotlin. Welche Sprachwerkzeuge ermöglichen eine sichere Arbeit mit null-Werten? Geben Sie ein Codebeispiel und beschreiben Sie die besten Praktiken.

Bestehen Sie Vorstellungsgespräche mit dem Hintsage-KI-Assistenten

Antwort.

Kotlin ermöglicht eine sichere Arbeit mit null durch das Typsystem: Jeder Typ kann standardmäßig nicht null sein, z.B. führt val a: String = null zu einem Kompilierfehler. Um die Möglichkeit zu kennzeichnen, null zuzuweisen, wird das Fragezeichen ? verwendet, z.B.:

val name: String? = null

Zur Arbeit mit Nullable-Typen stehen folgende Werkzeuge zur Verfügung:

  • Safe-call-Operator: ?., der null zurückgibt, wenn das Objekt selbst null ist, und die Methode/Feld andernfalls aufruft: name?.length.
  • Elvis-Operator: ?:, um einen Standardwert festzulegen, wenn links null ist: val length = name?.length ?: 0
  • Überprüfung durch if/when: Beispiel:
if (name != null) { println(name.length) }
  • Assert-Operator ( !! ): Um den Wert zwangsweise zu erhalten, wobei eine NullPointerException ausgelöst wird, wenn das Objekt null ist (wird sehr vorsichtig verwendet):
val length = name!!.length

Beste Praktiken: Minimieren von Nullable-Typen, Verwendung des Safe-call- und Elvis-Operators, Vermeidung von !!, explizite Modellierung von Situationen, in denen null zulässig ist.

Fangfrage.

Kann man dem Typ val a: String den Wert null zuweisen, und wie kann man das vermeiden?

Ergebnis: Nein, standardmäßig können Typen in Kotlin nicht gleich null sein. Um die Zuweisung von null zu ermöglichen, muss man ausdrücklich angeben val a: String? = null. Typen ohne ? sind immer non-null.

Beispiele für reale Fehler aufgrund fehlenden Wissens über die Feinheiten des Themas.


Geschichte

In einem Projekt einer Bankanwendung speicherte eine Variable des Typs User das Ergebnis der Kundensuche. Der Entwickler definierte var user: User, aber manchmal wurde der Kunde nicht gefunden und der Dienst gab null zurück. Dies führte zu NPE und massiven Abstürzen.


Geschichte

In einem Chatbot für Support wurde !! verwendet, um auf die Nachrichten des Benutzers zuzugreifen (message!!.text), in der Annahme, dass Nachrichten immer kommen. Der Bot stürzte beim ersten leeren Nachricht ab. Safe-call hätte das Problem beseitigt.


Geschichte

In einer mobilen Anwendung konnten Daten aus der Datenbank nicht geladen werden und kamen als null an. Anstatt sicheren Zugriff zu verwenden, verwendete der Entwickler direkten Zugriff, was zu Abstürzen in allen Fällen unvollständiger Daten führte.