Nullable types and safe calls
Nullable types and safe calls
A student may not have a recorded mark yet. Zero is a valid numerical value and should not also silently mean missing. A nullable type such as Int? permits either a number or null, making absence part of the declared contract.
What you’ll learn
- Represent absence with a nullable type.
- Use safe calls and meaningful fallbacks.
Nullable types and safe calls in the example
Absent score
A student may not have a recorded mark yet.
Absent scoreSafe access
The compiler restricts unsafe access to nullable values.
Safe accessExplicit fallback
The absent score uses the display fallback -1.
Explicit fallback
Understand nullable types and safe calls
The compiler restricts unsafe access to nullable values. A safe call such as name?.length produces null when the receiver is absent. The Elvis operator ?: provides a chosen fallback. The non-null assertion !! can throw if its assumption is false.
Follow nullable types and safe calls
Save the complete source as Main.kt and use the Kotlin/JVM environment. No separate input file is needed.
Kotlin/JVM · complete program
fun main() {
val score: Int? = null
val name: String? = "Diya"
println(score ?: -1)
println(name?.length ?: 0)
}Expected output
-1
4Follow the execution
The absent score uses the display fallback -1. The name is present and has four code units. The optional score itself remains absent; printing a fallback does not create a recorded mark.
Try this in the Kotlin compiler by pasting the complete program.
Practice: Nullable types and safe calls
Your task: Would replacing null with zero preserve missingness?
Kotlin/JVM · complete program
fun main() {
val score: Int? = null
val name: String? = "Diya"
println(score ?: -1)
println(name?.length ?: 0)
}Worked answer
No. A real zero and an absent result would become indistinguishable without another convention. Keep the nullable representation and choose an honest display message.
Nullable types and safe calls: the important boundary
Null safety prevents many mistakes but is not a blanket no-crash guarantee. Assertions, initialization issues and Java platform types still require care. Choose fallbacks that make domain sense rather than letting a sentinel participate in report arithmetic.
Check your understanding
Check the practical consequence
Nullable types and safe calls: what to keep in mind
No. A real zero and an absent result would become indistinguishable without another convention. Keep the nullable representation and choose an honest display message. Null safety prevents many mistakes but is not a blanket no-crash guarantee.
Further reading: official Kotlin documentation for this topic.
Reaching the recap and completing the quizzes are separate milestones.