Introduction

Kotlin's lateinit modifier exists for properties that cannot be initialized in the constructor but still should behave like non-null values later. The feature is useful, but it comes with one rule you cannot ignore: reading a lateinit property before assignment throws UninitializedPropertyAccessException.

How lateinit Works

You can apply lateinit only to mutable, non-primitive properties. Kotlin uses it for cases such as dependency injection, view binding, and test setup where a value is guaranteed to arrive later.

1class UserSession {
2    lateinit var token: String
3
4    fun initialize(value: String) {
5        token = value
6    }
7}

This compiles even though token has no initial value. The responsibility shifts to you: initialize it before first use.

Checking Initialization With isInitialized

Kotlin exposes isInitialized on a property reference. That is the standard way to check a lateinit property safely.

1class UserSession {
2    lateinit var token: String
3
4    fun printStatus() {
5        if (this::token.isInitialized) {
6            println("Token is $token")
7        } else {
8            println("Token has not been initialized")
9        }
10    }
11}
12
13fun main() {
14    val session = UserSession()
15    session.printStatus()
16    session.token = "abc123"
17    session.printStatus()
18}

This example is runnable and prints a safe message before initialization, then prints the token afterward.

The syntax matters. You are not checking the value directly. You are asking Kotlin about the property reference with this::token.isInitialized.

Scope Rules You Need to Know

isInitialized is only available where the property reference is accessible. In practice, that usually means inside the same class, inside an outer class for an inner property that is visible, or in test code that owns the property.

1class ServiceHolder {
2    lateinit var serviceName: String
3
4    fun isReady(): Boolean {
5        return this::serviceName.isInitialized
6    }
7}
8
9fun main() {
10    val holder = ServiceHolder()
11    println(holder.isReady())
12    holder.serviceName = "billing"
13    println(holder.isReady())
14}

Trying to check holder::serviceName.isInitialized from unrelated code often fails because the compiler restricts that usage.

When a Nullable Property Is Better

Developers sometimes use lateinit when a nullable type would express the state more honestly. If the value is optional, String? is often clearer than lateinit var String.

1class ReportBuilder {
2    var title: String? = null
3
4    fun printTitle() {
5        println(title ?: "No title assigned")
6    }
7}

This approach avoids property-reference checks and makes the unset state explicit in the type system.

Using lazy for Read-Only Deferred Initialization

If the value should be initialized once and then never reassigned, lazy is a better fit than lateinit.

1class ConfigLoader {
2    val configText: String by lazy {
3        println("Loading configuration")
4        "port=8080"
5    }
6}
7
8fun main() {
9    val loader = ConfigLoader()
10    println(loader.configText)
11    println(loader.configText)
12}

Here initialization happens automatically on first access, and Kotlin guarantees the property is ready when returned.

A Practical Testing Pattern

lateinit is common in tests because setup methods often assign shared fixtures.

1import kotlin.test.Test
2import kotlin.test.assertTrue
3
4class UserServiceTest {
5    lateinit var serviceName: String
6
7    @Test
8    fun setupStateCanBeChecked() {
9        assertTrue(!this::serviceName.isInitialized)
10        serviceName = "user-service"
11        assertTrue(this::serviceName.isInitialized)
12    }
13}

This keeps the test readable while still protecting against accidental early access.

Common Pitfalls

The most common pitfall is assuming lateinit behaves like an optional value. It does not. Access before assignment is a runtime failure, not a null result.

Another mistake is trying to use lateinit on primitive types like Int. Kotlin rejects that because primitives always need a concrete value representation.

A subtler problem is overusing lateinit in domain models. If an object is invalid until several properties are assigned later, the constructor is probably not expressing the real invariants of the type.

Developers also get tripped up by scope. isInitialized is not a universal reflection trick you can call anywhere. It works where the property reference is visible and supported by the compiler.

Summary

• Use this::property.isInitialized to check whether a lateinit property has been assigned.
• 'lateinit is for mutable, non-null, non-primitive properties.'
• Prefer nullable properties when the value is genuinely optional.
• Prefer lazy when a value should be computed once on first access.
• Treat lateinit as a delayed guarantee, not as a replacement for good object design.