Tony Hoare & Nulls

Nulls – or null reference is a programing concept where the language allows for a null value to be set to a variable. A null is a nothing value. There is nothing there.

Not only is this a programming concept, but it followed through with database schemas, that some elements can be null. For example, a Front End UI might ask you to register with the following fields:

• First Name
• Last Name
• E-mail
• Phone Number (optional)

In a framework like Grails or other web frameworks (like Rails) you determine which data elements can accept null values. In the above fields, phone number is optional, so it could be blank/empty – i.e. it could be null.

In such a situation the data might show “null” in the database for a variety of users who didn’t input a phone number value on registration.

The Father of Null Reference

The null reference was created by Sir Tony Hoare. While it seems quite useful to use null references (and I’ve certainly used them), they can become problematic.

Consider the above fields, where phone number could be blank. So in many cases we’ve set it to the value of null. Along comes another developer tasked with standardizing the phone numbers into one format. The format is to remove all spaces and dashes (-), so if someone entered 1-877 321-4329 this developer wrote code to take those values from the database and process them back as without the spaces and sashes: 18777214329.

What happens when they pull up a user’s phone number and it’s null? Without any null check, they will certainly throw an error. Now, realistically it’s not that hard to introduce null checks and yet Null Pointer Exceptions (a value being null when it isn’t expected to be null) is the most common error type in Java applications.

In 2009 Tony Hoare offered an apology of sorts, for his introduction of the null reference. As applications became far more massive, the use of null references became a hazard, leading to crashes, vulnerabilities and other failure points in application development and maintenance.

Null Safety in Java, Groovy & C++

In some languages, an Option type was allowed to determine if a field can be null or not. In other languages, like Java Option types can be added to wrap around an object like so:

Optional<Username> registration = new Client();

This allows for a null to pass through, or if a non-null value to take it.

More simplistic ideas can done with method checks:

if thatValue != null .... { do a bunch of stuff };

While Java, C++ have the Options, Groovy introduces the ? symbol. By appending ? to an object we are allowing the object to be null, but not throwing a NPE.

user?.phoneNumber?[-2..-1]

In the above Groovy syntax, we’re grabbing the instantiated user, who may (or may not) have a phone number. The ? allows the object to be null. If it’s null, no error or fail point will occur. If it has a value, then in this case we take the value and get the last 2 digits from the phone number.

Due to the nature of teams and fast turn around, often mistakes fall into these nullable objects.

In other words, as historic languages allow null references by default, it relies on the developer for institute null safety.

In looking at what developers tend to defend on this issue, the issue of null reference is often defended. The main argument is that there’s always going to be blank data or data that changes state to being null.

Those who defend NPE (Null Pointer Exceptions) say that failing fast (with NPE’s) is a better option than hiding them under some sort of handler (like Options.)

While that may be true (failing fast) it still leads us to the conclusion from Tony Hoare, who said this was his Billion Dollar Failure. As NPE’s introduce vulnerabilities and catastrophic failure that wasn’t caught FAST. In other words, edge cases not caught in development, make it out to the wild where users create the scenario and now the FAIL FAST event is happening live. Potentially causing loss of revenue, costumers or complete security vulnerabilities.

Kotlin & Null Safety

While Java, C++ and Groovy have implementations to work around null values, it leaves it up to the developer to implement. On growing teams or fast moving projects, these checks may not make it to prime time.

What if a language had as its default behavior, an inability to allow an object to take on a null reference? Then, if null is required, a syntax similar to Groovy’s is implemented.

The difference between Groovy’s implementation and Kotlin’s, is that Kotlin will not allow null assignments. One has to specifically allow null assignments using the ? symbol.

var phoneNumber: String? = null

In the Kotlin syntax above, the phoneNumber is being set to null. You can not set it to null without the ? syntax.

If a method is invoked on phoneNumber, like .length the code won’t compile – which stops the problem from even reaching the end user – no runtime exception.

Once we have a variable that can be nullable (as defined above) we can use the Groovy-like syntax for a “safe call.”:

phoneNumber = "18887772318"
phoneNumber?.length

Thoughts

While this no doubt helps with development phases, I still don’t see how Kotlin prevents null reference issues in production.

For example, a developer could create consume those fields at the top of this article, and set phoneNumber as a value (or variable) without null safety. All would appear well in the developer side. But once the user enters no value in the form, won’t this still throw a null exception of some sort, at runtime?