All posts for the month February, 2015

Christian Neumanns considers that null should not be hated, as elaborated in his article Why We Should Love null. Essentially he concludes that the compiler should treat nullable fields as though they are option/maybe types, and should prevent use of the values before they have been checked for nullity. Some notes follow, as far as I maintained interest.

Therefore some developers try to avoid null. For example, they use 0 instead of null in case of a number value, or their functions return an empty list or an empty string instead of null.

In some cases an empty string is a reasonable substitute for no value. I am thinking particularly of display in a user interface, where showing no characters may be the right thing to do when there is no value. 0 is far more dubious. Some developers doing the wrong thing is more a comment on those developers than it is on the validity of using null. I would not be at all surprised to hear those same developers generating plenty of null pointer errors back in their null-using days.

In real life, we are all used to the notion of ‘nothing’ appearing in thousands of different ways.

This is a total red herring. The problem with null has nothing to do with whether it is reasonable to have a representation of the concept of “nothing”. The problem is when developers fail to consider what their code will do if it gets “nothing”. I suppose this is because we write code to take particular types of inputs and manipulate them, and nothing is not a type of something. For example if I ask someone to hand me a pencil, I am not expecting them to make the motion of handing me a pencil with nothing in their hand – that would be nonsensical.

More than an astonishing 99.999% of the universe is nothing – just empty space.

Make that a very large red herring.

Instead of using a non-null value to represent ‘no data available’ it is (in most cases) much better to use null.

Yes, we increase the risk for null pointer errors. But we decrease the risk for outcomes that are worse, such as delivering wrong results without any error message and other unacceptable or catastrophic situations – for example letting users buy houses for free.

This is true, but also a moot point. Why accept either possibility?

‘unhappy’ is better than ‘very unhappy’.

And both are worse than ‘happy’. This attitude looks how the result of years of doing the best that Java will allow.

Hence, we should embrace null and make it our friend and … love it!

Odd to make such a conclusion before looking at the more relevant alternatives…

Don’t use the Null Object pattern just to avoid null pointer errors.

This, and the reasoning behind it, I agree with. Null is problematic because it can sneak in where an actual something is expected (in many languages). Introducing something else that can do the same is no solution at all. They may have their place though. Again I am thinking of a user interface that could reasonably have a blank space when there is nothing to display – if there is an object that is just giving text to display, a null object that gives empty strings might make for more readable UI code than putting all the conditional display logic in the UI code itself.

If we call get() without first checking the presence of data with isPresent() then we get a NoSuchElementException if there is no value present.

It is a shame that Java is not expressive enough to give a compiler error for this. As a best-effort approximation, a boolean field that is false, and set to true when isPresent() is called would help to catch many of these cases. It would still be a runtime error, but the error would happen any time the code runs so the developer is far more likely to see it before it can cause problems for a user. A major limitation is that as soon as the option container has been checked once it will no longer throw an error, even if it is passed around to different scopes in which its contents have not been confirmed as non-null.

If a method is declared to return an Optional, nothing prevents the programmer who implements the method from (involuntarily) returning null instead of returning a non-null Optional.

This is a weakness of Java, rather than of the Optional pattern.

If we accidentally construct an Optional by calling method of() with null as input, we get a NullPointerException.

This is an advantage over plain null, since it moves the error closer to the origin of the null value. The problem here only exists because of the use of null in the first place. In an ideal world this is something that only I/O drivers would have to deal with. Java is a long way from any kind of ideal world.

The compiler cannot force programmers to use Optional in their own methods. It is up to the programmer to decide whether he/she returns an Optional or simply sticks to returning null in case of no data.

Unless the programmer has heard of static analysis, that is…

Existing standard Java libraries cannot be retrofitted to use Optional because this would break backwards compatibility.

They cannot be retrofitted, but they can be wrapped in facades. A disciplined developer could approach some semblance of sanity in their own code that way.