How to Check Whether a lateinit Variable Is Initialized in Kotlin

By the end of this page, you will understand what Kotlin lateinit properties are, how to check whether they have been initialized, when that check is useful, and what alternatives like nullable properties or lazy delegation may be better in some situations.

lateinit in Kotlin lets you declare a non-null var without assigning a value immediately.

lateinit var name: String

This is useful when a value cannot be created at object construction time, but you promise it will be assigned before use.

However, if you access a lateinit property before assigning it, Kotlin throws an UninitializedPropertyAccessException.

That is exactly the risk in this example:

private lateinit var myFile: File

If bar2() runs before bar() assigns myFile, the program can crash.

Kotlin provides a built-in way to check whether a lateinit property is initialized:

this::myFile.isInitialized

This uses a property reference. It asks Kotlin for metadata about the property and returns true if the property has already received a value.

Think of a lateinit property like a locker with a label on it, but nothing has been placed inside yet.

• Declaring the locker means the space exists
• Initializing it means putting the item inside
• Accessing it before putting anything inside causes an error
• isInitialized is like checking whether the locker already contains something

So instead of blindly opening the locker and expecting an item, you first check whether it has been filled.

The basic syntax for checking a lateinit property is:

if (this::myProperty.isInitialized) {
    // safe to use myProperty
}

Example with your case

import java.io.File

class Foo {
    private lateinit var myFile: File

    fun bar(path: String?) {
        path?.let { myFile = File(it) }
    }

    fun bar2() {
        if (this::myFile.isInitialized) {
            println(myFile.path)
        } else {
            println("myFile is not initialized yet")
        }
    }
}

What this does

• this::myFile creates a reference to the property
• .isInitialized checks whether the lateinit variable has been assigned
• If it has, you can use myFile
• If not, you handle that case safely

Consider this example:

import java.io.File

class Foo {
    private lateinit var myFile: File

    fun setFile(path: String?) {
        path?.let { myFile = File(it) }
    }

    fun printFilePath() {
        if (this::myFile.isInitialized) {
            println(myFile.path)
        } else {
            println("No file has been set")
        }
    }
}

Now trace it step by step.

Case 1: property not initialized

val foo = Foo()
foo.printFilePath()

Execution:

1. Foo() creates an object
2. myFile exists as a lateinit property, but no value has been assigned yet
3. printFilePath() runs
4. this::myFile.isInitialized returns false

lateinit initialization checks appear in situations where setup happens later than object creation.

Android and UI lifecycle

A view or binding object may be assigned in a lifecycle method and accessed later.

if (this::binding.isInitialized) {
    binding.textView.text = "Ready"
}

Dependency injection

A dependency may be injected after construction.

lateinit var repository: UserRepository

Before using it in some special flow, you might verify it has been assigned.

Test setup

In unit tests, objects are often initialized in @Before methods.

lateinit var service: UserService

A check can help in utility methods if setup is conditional.

Delayed resource creation

A file, socket, parser, or cache object might only be created if configuration is valid.

path?.let { myFile = File(it) }

Then later code can safely check whether setup succeeded.

Optional component wiring

In real projects, developers usually use lateinit carefully and combine it with clear control flow.

Common pattern: guard clause

fun processFile() {
    if (!this::myFile.isInitialized) return
    println(myFile.path)
}

This is simple and avoids deeply nested if statements.

Common pattern: fail fast with a clear message

fun processFile() {
    check(this::myFile.isInitialized) { "myFile must be initialized before calling processFile()" }
    println(myFile.path)
}

This is useful when missing initialization is a programmer error, not a normal runtime case.

Common pattern: initialize in one place

Instead of checking everywhere, many codebases centralize setup.

fun initialize(path: String) {
    myFile = File(path)
}

Then other methods assume initialization has already happened.

Common pattern: prefer nullable when absence is valid

1. Accessing a lateinit property without checking

Broken code:

fun bar2() {
    println(myFile.path)
}

Problem:

• This crashes if myFile was never assigned

Fix:

fun bar2() {
    if (this::myFile.isInitialized) {
        println(myFile.path)
    }
}

2. Using lateinit when null is a valid state

Broken design:

private lateinit var selectedFile: File

Problem:

• If "no file selected yet" is a normal state, lateinit hides that fact

Better:

private var selectedFile: File? = 

lateinit vs nullable

lateinit var name: String

Check initialization:

if (this::name.isInitialized) {
    println(name)
}

Guard clause pattern:

if (!this::name.isInitialized) return

Fail-fast pattern:

check(this::name.isInitialized) { "name must be initialized" }

Rules:

• lateinit works only with var
• property must be non-null
• not allowed for primitive types like Int or Boolean
• accessing before initialization throws UninitializedPropertyAccessException
• isInitialized works only for lateinit properties

Prefer nullable instead when missing data is normal:

How do I check if a lateinit variable is initialized in Kotlin?

Use a property reference with isInitialized:

if (this::myFile.isInitialized) {
    // use myFile
}

What happens if I access a lateinit property before initialization?

Kotlin throws an UninitializedPropertyAccessException at runtime.

Can I use lateinit with val?

No. lateinit only works with mutable properties declared using var.

Can I use lateinit with Int or other primitive types?

No. lateinit is not allowed for primitive types.

Should I use lateinit or a nullable property?

Use lateinit when the value should never logically be null but is assigned later. Use a nullable property when absence is a normal state.

• Nullable types — related because they are the main alternative when a value may be missing.
• Safe call operator (?.) — useful when working with nullable properties instead of lateinit.
• Elvis operator (?:) — commonly used to provide fallback values for nullable properties.
• Property references — this::myFile is a property reference used for isInitialized.
• Lazy initialization — another delayed initialization technique using by lazy.
• Constructor injection — a cleaner approach when a dependency is required from the start.
• Guard clauses — often used with isInitialized to exit early when setup is incomplete.
• Exception handling — relevant because incorrect lateinit access throws a runtime exception.