Benefits of Null Safety

I will assume that you come from Java, you already looked at some explanations somewhere else and did not fully understand them. Therefore, I will not try to give you a comprehensive explanation (which you can find elsewhere) but instead I will try to make clear the core idea of null pointer safety.

There are two points that, if you understand them, should make it clear enough. First, there is the idea of having two separate types to represent what you would model as a single type in Java: nullable ones and not nullable ones. To give you an example, while in Java you put a string in a String object, without caring if the string can be null or not, in Kotlin you have two types: String? and String. The first accepts null values (like the Java equivalent) but the second does not. So you can have null values in types with a ? (like String? or Int?) but there are a lot of restrictions on what you can do with those: basically you are restricted to the things you can do with a null, because, after all, the variable could be holding a null value. So no calling of method on it, for instance. So, while in Java you could call a method on it and have a NullPointerException sometimes, in Kotlin you cannot call any methods. And this is not because of some silent behavior of Kotlin, it’s much simpler than that: the compiler won’t let you. Try and you will see that the program does not compile. If the variable was of type String instead of String? then Kotlin would allow you to call methods from it.

So, basically, no null pointer exceptions because you can never call a method on an object variable that could be null.

But then, sometimes the variable is not null: so how could you call the method on the variable in those cases where the variable is not null? Again, the answer is simple: you have to check it. I mean, you have to use an if instruction (explicitly or implicitly) that will check if the variable is null or not. Something like “if (myVariable != null) {call method on variable}”. So, as you can see, the Kotlin compiler is clever enough to see that you used an if instruction that guarantees that the variable is not null, so it will let you call methods on the variable in the block between { and }. In other words, if your variable is of type String? but you are inside an if block where you checked that the variable is not null, Kotlin will treat it like a variable of type String instead of String?

When you speak about

some part the code which silently won't be executed

I am guessing you are thinking about some operators that have an implicit if inside of them, like the ?. operator. If you write

myVariable?.call()

it means roughly

if (myVariable != null) { myVariable.call()}

So, indeed, if the variable is null, it will “fail” silently. But this is not different than Java if you use the same kind of if. In other words, nothing will happen if the variable is null because you explicitly coded it to behave like that.

The main benefit is that the code which can potentially cause a NullPointerException does not compile. The only situation when you get "part of code which silently won't be executed" is when you use safe calls to deal with a potential nullability error. This is not the only, and not the most useful, way to deal with such errors.