← Powrót do Bazy wiedzy← Poprzednie pytanieNastępne pytanie →
programowanieProgramista Kotlin

Wyjaśnij cechy pracy z typami Nullable w Kotlin. Jakie narzędzia języka pozwalają bezpiecznie pracować z wartościami null? Podaj przykład kodu i opisz najlepsze praktyki.

Zdaj rozmowy kwalifikacyjne z asystentem AI Hintsage

Odpowiedź.

Kotlin realizuje bezpieczną pracę z null dzięki systemowi typów: każdy typ domyślnie nie może być null, na przykład val a: String = null spowoduje błąd kompilacji. Aby oznaczyć możliwość przypisania null, używa się znaku zapytania ?, na przykład:

val name: String? = null

Do pracy z typami Nullable dostępne są:

  • Operator bezpiecznego wywołania: ?., który zwraca null, jeśli obiekt jest null, i wywołuje metodę/pole w przeciwnym przypadku: name?.length.
  • Operator Elvisa: ?:, aby ustawić wartość domyślną, jeśli z lewej strony jest null: val length = name?.length ?: 0
  • Sprawdzanie przez if/when: Przykład:
if (name != null) {
    println(name.length)
}
  • Operator assert ( !! ): Wymusza pobranie wartości, rzucając NullPointerException, jeśli obiekt jest null (używany bardzo ostrożnie):
val length = name!!.length

Najlepsze praktyki: minimalizować typy Nullable, używać operatora bezpiecznego wywołania i operatora Elvisa, unikać !!, jawnie modelować sytuacje, w których null jest dozwolony.

Pytanie z haczykiem.

Czy można przypisać typowi val a: String wartość null, i jak tego uniknąć?

Odpowiedź: Nie, domyślnie w Kotlinie typy nie mogą być równe null. Aby pozwolić na przypisanie null, należy wyraźnie wskazać val a: String? = null. Typy bez ? są zawsze non-null.

Przykłady rzeczywistych błędów z powodu braku znajomości szczegółów tematu.

Historia

W projekcie aplikacji bankowej zmienna typu User przechowywała wynik wyszukiwania klienta. Programista zdefiniował var user: User, ale czasami klient nie był znajdowany i serwis zwracał null. To powodowało NPE i masowe awarie.

Historia

W czacie-bocie do wsparcia używano !! do uzyskania dostępu do wiadomości użytkownika (message!!.text), zakładając, że wiadomości zawsze przychodzą. Bot padał na pierwszej pustej wiadomości. Bezpieczne wywołanie pozbyłoby się problemu.

Historia

W aplikacji mobilnej dane z bazy mogły nie być załadowane i przychodziły jako null. Zamiast bezpiecznego dostępu programista użył bezpośredniego dostępu, co prowadziło do awarii w każdym przypadku niepełnych danych.