In Kotlin there appears to be two method of declaring a variable inside an object that can be null and instantiated after the object is created.
var myObject : Any? = null
var lateinit myObject : Any
I am confused about why the lateinit keyword is needed if we can just make the var nullable and assign it later. What are the pros and cons of each method and in what situation should each one be used?
Here is how I see the difference according to my current knowledge in Kotlin.
var myObject1 : Any? = null
myObject1 is a property that is nullable. That means you can assign
null to it.
lateinit var myObject2 : Any
myObject2 is a non-null property. That means you cannot assign
null to it. Usually if a property is non-null you have to initialize it at the declaration. But adding the keyword
lateinit allows you to postpone the initialization. If you try to access the
lateinit property before initializing it then you get an exception.
In short the main difference is that
myObject1 is a nullable and
myObject2 is a non-null. The keyword
lateinit provide you a convenience mechanism to allow a non-null property to be initialize at a later time rather than initializing it at the declaration.
For more info check this.
lateinit keyword is used on a field to
avoid null checks when referencing the field inside of your object. The keyword is mainly used when you are using dependency injection to initialize the variable, or initializing the variable in the setup method of a unit test
? is used on a field when the field will be initialized later in your program either by a setter or inside of a method of the object, this is to enforce you to check for null or use null safety(
?.) when referencing the field
If your property should not be
null, but just isn’t set after some point in the future, it is safer to declare it with a
lateinit keyword. That guarantees that, if you access it before it is set, you get an exception explaining exactly that.
The traditional Java way is to throw a generic
NullPointerException with no explanation about it. If you wrote the code yourself, you might have a clue, but if someone else catches the error, it won’t be clear why that particular variable is