One of the most annoying aspects in writing code in Java is dealing with null elements. Having to place null check conditions everywhere just to make our code null-safe is something that probably most of us have suffered quite often.
Kotlin provides different mechanisms to help solve this problem. Let’s go through them first.
By default Kotlin types are not nullable, what means that it’s impossible to assign null to them. That’s definitely the best way to avoid having to deal with nulls in our language; although is this always possible?
Not always, we might have a
findEmployee method in our service where we want to express the possibility of not finding the employee by using a Nullable type.
If we take the example we used in our last Kotlin article about Either:
We can slightly modify it to include the possibility of not finding the employee; to achieve that we’ll use a nullable type. We could also use a
Problem for that, but that would depend if you want to represent that as a valid business case or as an exceptional case. In our case we’d go for the option of using a nullable type. So how would it look like?
As you can see, we have mapped a 404 (NOT_FOUND) response to a null
Employee for our nullable
How would this be handled from the client side? Let’s take a quick look.
Handling Nullable Types
One of the things that Kotlin beginners tend to do is to use the
!! operator every time a compilation issue has to be solved between a nullable and non-nullable type. This is a big mistake and it should be avoided;
!! will throw a
NullPointerException if the instance is null. As a rule of a thumb, always avoid using
!! operator unless that it’s really necessary.
If we take our
PayrollService as an example, we could for example have this:
That’s simple but unfortunately it will raise a
NullPointerException when our employee is null; if you’re thinking about catching it and then do something else with it, please don’t!
So what can we do to avoid using
!! operator then? Let’s see what other options we could have.
One of the options is of course to check if the instance is null with an
If checks are a bit verbose though and they can pollute our code considerably. We can take our
PayrollService as an example to see how all these options would look like; once we introduce null checks it would be something like this.
Although this option is not a bad way of handling it, one of the problems in using if conditions is that it takes multiple lines just to do a very simple check, something that will end up polluting our code in multiple places. In our example it might be not so obvious but what if we just want to log a field? We’d have to embed a whole if condition in our logger statement or do some checks before calling it. So ideally we’ll need something much more concise to be able to use it in a one-liner.
Another problem of null checks is that it’s not an atomic operation, so in the cases when we’re dealing with mutable instances we could fall into big problems due to the value changing right after the null check.
We could also use a more concise version of our
if condition, although this is not ideal either and won’t solve some of the issues null checks brings.
Let’s see what else could we do in Kotlin.
A good tool Kotlin provides are safe calls. We can make use of safe calls by using the operation ?. ; this will safely access a null instance or its properties. We could also apply an operation over that instance by executing any action over it using let method.
It’s worth mentioning that a safe call will return null if the instance was null. For instance
employee?.name will be “safely” returning null if the employee instance was null, instead of raising a
For example, let’s say we want to log the employee name in one of our log statements. We could easily do that as shown below; in the case of our employee being null,
null will be printed in our log.
This leads to the next question; what if we want to provide a default value for the employee name in our log?
The elvis operator allows us to define a non-nullable value to be used in the case that the left hand-side returns null.
For example, in we wanted to define a default value in our log statement we could have something as:
As simple as that!
Now knowing all we’ve learned, what would be the best way to handle a nullable type from our
Putting all together
With all the options we have now a clean, concise, safe and expressive way to handle a nullable
Employee type could be something like this:
That looks concise and clean; there could be some arguments against it due to not being “human-readable” but I can promise that once you get used to the use of safe calls and
let methods you’ll read it clearly with no effort.
It’s also worth mentioning that if you are working with mutable variables (something I would NOT recommend), using
let is safer than using an
if condition. This is because the value passed to the lambda inside the
let method will not change even if the original variables changes its value; that will make your block much safer in this particular case.
Kotlin has made big improvements into one of the areas where Java has been highly criticised due to all the problems caused around it. People like Tony Hoare have even apologised for inventing null in the first place, so we’re not talking about a trivial problem; this has been costly and painful in many languages for a variety of reasons.
That’s all for now! We hope you’ve really enjoyed and learned something useful this time! One last thing, if you feel you need to improve your Kotlin knowledge and need a good book, we recommend taking a look at Kotlin in action or Head First Kotlin. We consider these good resources to start learning Kotlin and have a basic understanding to start writing applications with it.
Thanks for reading us and please subscribe if you like our content!