Benefits of Null Safety

Question

I'm new to Kotlin and I've read that it seems to be the best invention after the wheel. That makes me suspicious anyway, certainly because I didn't understand everything the concept implies.

To resume what I understood, before we had NullPointerException so a very clear idea about something is wrong in the code and where the problem occurs but not where the null was set. Anyway, it was quite clear that we could wait here until the null pointer comes back expecting understand what happened from the backtrace. Everybody did that already, that's never impossible to find.

Now with Null Pointer Safety, we do not have such crash anymore, just some part the code which silently won't be executed in our application (we assume the reference used is not supposed to be null as before, of course), causing maybe strange behavior even more complicated to understand than the NullPointerException before, or maybe just some tasks not executed for month before someone realize it.

Is it the benefits Null Pointer Safety offer?

Answer 1

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.