Null Safety

Introduction

Null safety is the feature Kotlin is most famous for, and the single biggest reason many teams migrate from Java. Tony Hoare, who invented the null reference in 1965, later called it his "billion-dollar mistake" because of how many production crashes it has caused across the software industry. Kotlin's type system tackles this head-on by making nullability an explicit, checked part of every type.

This lesson covers nullable types, the operators Kotlin gives you to work with them safely (`?.`, `?:`, `as?`), the not-null assertion `!!` and why to use it sparingly, and how smart casts eliminate manual null checks after you've already proven a value isn't null.

Nullable vs Non-Nullable Types

Every type in Kotlin is non-nullable by default. To allow a variable to hold `null`, you must explicitly mark its type with a trailing question mark, e.g. `String?` instead of `String`. The compiler then tracks this distinction everywhere and refuses to compile code that could dereference a nullable value without first checking it.

fun main() {
    var name: String = "Kotlin"
    // name = null                // Compile error: String cannot hold null

    var nickname: String? = "Kt"
    nickname = null                // OK — String? can hold null

    // println(nickname.length)   // Compile error: nickname might be null
    println(nickname?.length)     // OK — handled safely, prints "null"
}

The Safe Call Operator ?.

The safe call operator `?.` accesses a property or calls a method only if the value on its left is not null; otherwise, the entire expression short-circuits to `null` instead of throwing. It can also be chained across multiple nullable steps.

class Address(val city: String?)
class Customer(val address: Address?)

fun main() {
    val customer: Customer? = Customer(Address("Mumbai"))
    val noAddress: Customer? = Customer(null)

    println(customer?.address?.city)     // Mumbai
    println(noAddress?.address?.city)     // null — no crash
}

The Elvis Operator ?:

The Elvis operator `?:` provides a fallback value to use when the expression on its left is null. It is commonly chained right after a safe call, giving you a one-line "use this value, or a default if it's null" pattern.

fun main() {
    val nickname: String? = null
    val displayName = nickname ?: "Anonymous"
    println(displayName)

    val length = nickname?.length ?: 0
    println(length)
}

The Elvis operator gets its name from the `?:` symbol, which — turned sideways — resembles Elvis Presley's hairstyle and eyes. It can also be used with `return` or `throw` on the right-hand side to exit a function early when a value is unexpectedly null.

The Not-Null Assertion !!

The `!!` operator forcibly converts a nullable type to its non-null counterpart, telling the compiler "trust me, this is definitely not null." If you are wrong, it throws a `NullPointerException` immediately — exactly the exception Kotlin's null safety exists to prevent.

fun main() {
    val name: String? = "Kotlin"
    val length: Int = name!!.length   // asserts name is not null
    println(length)

    val missing: String? = null
    // val crash = missing!!.length   // throws NullPointerException at runtime
}

Safe Casts with as?

The regular `as` cast throws a `ClassCastException` if the value isn't the target type. The safe cast operator `as?` instead returns `null` if the cast fails, letting you handle the mismatch gracefully instead of crashing.

fun main() {
    val value: Any = "Hello"
    val asInt: Int? = value as? Int         // fails safely — value isn't an Int
    val asString: String? = value as? String

    println(asInt)
    println(asString)
}

Smart Casts After Null Checks

Once the compiler can prove a nullable value isn't null within a certain scope — for example, inside an `if (value != null)` block — it automatically treats that value as its non-null type for the rest of that scope. This is called a smart cast, and it means you rarely need `!!` after an explicit null check.

fun printLength(text: String?) {
    if (text != null) {
        println(text.length)   // smart-cast: text is treated as String here, no !! needed
    } else {
        println("No text provided")
    }
}

fun main() {
    printLength("Kotlin")
    printLength(null)
}

lateinit and Platform Types

Sometimes a non-null property genuinely can't be initialized in the constructor (a common example: Android views set up later in a lifecycle method). The `lateinit` modifier lets you declare a non-nullable `var` without an initial value, promising to set it before first use — accessing it too early throws a clear `UninitializedPropertyAccessException` rather than silently allowing null.

When Kotlin code calls into Java code, values coming from Java have no compile-time nullability information (Java has no `?` syntax), so Kotlin treats them as "platform types," shown as `String!`. You can treat a platform type as either nullable or non-nullable, but the compiler cannot protect you there the way it can with pure Kotlin code — so it is worth being extra careful at Java interop boundaries.

class UserSession {
    lateinit var username: String

    fun login(name: String) {
        username = name
    }
}

fun main() {
    val session = UserSession()
    session.login("Elena")
    println(session.username)
}

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

You now understand Kotlin's null-safe type system in depth — its defining feature. Next, you'll put this together with Kotlin's built-in collection types: List, Set, and Map.