This document discusses avoiding a false sense of null safety in Kotlin code. It recommends using "?:" and throwing a custom exception instead of "!!", as this makes the assumption of non-nullability clear, allows logging if it occurs, and permits custom errors and fixes to be shown to users. Determining why a value is nullable in the first place is also suggested if the null situation should not be possible.

1. How to Avoid False
Sense of Null-Safety
by Oleksii Fedorov

2. What’s wrong here?

3. What’s wrong here?

4. What’s wrong here?
kotlin.KotlinNullPointerException
at mybackend.CompanyService.getCompany(CompanyService.kt:10)

5. What does “!!” mean?

6. What does “!!” mean?
“companyId” can’t be null at this point

7. What does “!!” mean?
“companyId” can’t be null at this point
WE ASSUME
“companyId” can’t be null at this point

8. Why do we assume that?

9. Why do we assume that?
NO. FLIPPING. IDEA.
🤷"

10. How can we encode the WHY?

11. How can we encode the WHY?

12. How can we encode the WHY?
?: throw YourAssumptionHere(“…”)

13. Why “?: throw” is better than “!!”

14. Why “?: throw” is better than “!!”
‣ Clear WHY it can’t be null

15. Why “?: throw” is better than “!!”
‣ Clear WHY it can’t be null
‣ Can grep logs to see if it happens

16. Why “?: throw” is better than “!!”
‣ Clear WHY it can’t be null
‣ Can grep logs to see if it happens
‣ Can show custom error to the user

17. Why “?: throw” is better than “!!”
‣ Clear WHY it can’t be null
‣ Can grep logs to see if it happens
‣ Can show custom error to the user
‣ Can tell user how to fix the “impossible situation”

18. Next step: Why is it nullable?
(If this situation is not possible)

19. Thank you!
Q & A