ProgrammatieKotlin ontwikkelaar

Leg de kenmerken uit van het werken met Nullable-types in Kotlin. Welke hulpmiddelen van de taal maken het veilig om met null-waarden te werken? Geef een codevoorbeeld en beschrijf de beste praktijken.

Slaag voor sollicitatiegesprekken met de Hintsage AI-assistent

Antwoord.

Kotlin implementeert veilig werken met null door middel van een typesysteem: elk type kan standaard niet null zijn, bijvoorbeeld, val a: String = null zal een compilatiefout veroorzaken. Om aan te geven dat het mogelijk is om null toe te wijzen, wordt het vraagteken ? gebruikt, bijvoorbeeld:

val name: String? = null

Voor het werken met Nullable-types zijn er:

  • Safe-call operator: ?., die null retourneert als het object zelf null is, en anders de methode/het veld aanroept: name?.length.
  • Elvis-operator: ?:, om een standaardwaarde in te stellen als links null is: val length = name?.length ?: 0
  • Controle via if/when: Voorbeeld:
if (name != null) { println(name.length) }
  • Assert operator (!!): Dwingt om een waarde te verkrijgen, en gooit een NullPointerException als het object null is (wordt heel voorzichtig gebruikt):
val length = name!!.length

Beste praktijken: minimaliseer Nullable-types, gebruik Safe-call en Elvis-operator, vermijd !!, modelleer expliciet situaties waarin null is toegestaan.

Valse vraag.

Kan je het type val a: String een waarde null toewijzen, en hoe dit te vermijden?

antwoord: Nee, standaard in Kotlin kunnen types niet gelijk zijn aan null. Om toewijzing van null toe te staan, moet je expliciet val a: String? = null opgeven. Types zonder ? zijn altijd non-null.

Voorbeelden van echte fouten door onbekendheid met de subtiliteiten van het onderwerp.


Verhaal

In een bankapplicatie bevatte een variabele van type User het resultaat van de zoektocht naar een klant. De ontwikkelaar definieerde var user: User, maar soms werd de klant niet gevonden en de service retourneerde null. Dit veroorzaakte NPE en massale crashes.


Verhaal

In een chatbot voor ondersteuning werd !! gebruikt om toegang te krijgen tot de berichten van de gebruiker (message!!.text), in de veronderstelling dat berichten altijd binnenkwamen. De bot viel bij het eerste lege bericht. Safe-call had het probleem kunnen vermijden.


Verhaal

In een mobiele applicatie konden gegevens uit de database niet zijn geladen en kwamen ze als null binnen. In plaats van veilig te verwijzen, gebruikte de ontwikkelaar directe toegang, wat leidde tot crashes in alle gevallen van onvolledige gegevens.