Introduction to Kotlin | Application of Kotlin Part 6
So by default, we don’t have nullable types. So when you declare a type in Kotlin, if I come here, and I say val my string equals some value, and then I do my string equals null, that’s not going to work, because it says this type is not nullable.
If I initialize it to null, then it will work. You can also do explicit type declaration in Kotlin. But you normally don’t, so I can do string something. That, again, is going to give an error because string does not nullable.
And one day, I will write something properly. Now, what I can do to make this nullable is add a question mark and now say this is actually now nullable, And so I can assign a nullable type to it. Why would you want to do this?
Again, try and move away from nullable types. In Kotlin, by default, you don’t declare nullable types. However, one of the purposes of creating Kotlin was to be able to interop with all of the existing Java code that we have and you have. And when you’re interoping with Java, you’re going to face nullable types.
So you need to have that question mark there sometimes to be able to interop with nullable types. So in the case of Kotlin, what we try and do is make it a little bit nicer to work with.
So here, you see that basically the same kind of code. In this case, I don’t have to do any checks, because it’s a customer Kotlin, and I’m saying that it’s not nullable.
In this case, however, given that this is coming from Java, I can actually explicitly say that this is going to be a nullable type by adding the question mark. Since I say it’s going to be a nullable type, then Kotlin.
I would have to do in line of if customer is not null, then do something with it. You can do a much shorter syntax with that by just using the question mark here.
So that’s basically saying if customer is not null, then if name is not null, then it starts with blah, blah, blah.
And if that equals true, then do something, So when you’re working with Java, you have to decide whether the type you’re actually working with is nullable or not.
I could actually remove this and say, there you go. I now know that this will never be null. So you can use the not null annotations that different libraries provide to kind of recognize whether that’s going to be nullable or not.
What you can’t do is remove that and then get null reference exceptions at runtime, and then say, well, didn’t Kotlin say that it removed null?
No, because you are explicitly saying that this is null. And as I always say, if you really want to be brave, what you can also do is declare this as nullable, and then do customer!!ID.
And that means I don’t care. I miss my null reference exceptions. I just want you to blow up at runtime. So you can do that as well.
While you’re at that, don’t start– this is one of the main things that people fall into, the trap.
When they start to pore over their Java code, initially, they’re like, oh, well, this is null. What shall I do? Double exclamation. No, you don’t.
Not having nulls in the language is actually forcing you to think more about nulls, essentially, because it’s not the happy path. Normally, when we do error control, it’s like, well, if it’s not null, I’ll do this.
And if it’s null, then I’ll pretend that nobody saw anything, Now it’s saying, what happens if it’s not null? Oh, I don’t know. So what else?