It’s like that time you played basketball in the living room. You knew you should never have done it. But it was just so tempting! And how did that work out for you? Broken lamp? Hole in the wall? And, if you grew up in a house like mine, a tanned hide to follow. You could have avoided it all: the property damage, the wounded pride, the tender backside.
That’s what playing with
null is like. You know you shouldn’t, but it’s just so easy! Then you get burned in the end.
The Problem with Null
The problem with
null is that it can crop up anywhere an object can. Consider a function that returns a string. This is always OK, right?
let foo : unit -> string = // ... let len = foo().Length // No worries?
It certainly is in this case:
let foo : unit -> string = fun () -> "foo" let len = foo().Length // val len : int = 3
But what about this?
let foo : unit -> string = fun () -> null let len = foo().Length // System.NullReferenceException: // Object reference not set to an instance // of an object.
Yeah, not so much. And the problem is that the compiler cannot help us:
null is a perfectly legal return value.
We need better semantics! A return type of
string ought to guarantee me that I get a
string. An empty string would be fine; it just needs to be a
Even the guy who invented the concept of null has regretted it:
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler.
But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Sir Charles Antony Richard “Tony” Hoare
Turing Award Winner, Inventor of the Quicksort
Null References: The Billion Dollar Mistake (2009)
Fine! All this lamenting that
null is a bad idea is great, but don’t you need a way to represent the idea that sometimes a function may not return a result, or at least, not what you would consider a valid result? That’s what Java does: If you call
Map.get(key), and that map does not contain an entry for
key, you get
null. As we saw couple of weeks ago, F#’s
List.find (and the other collections’
find functions, too) is not any more elegant: It throws an exception!
There’s got to be a better way!
Option to the Rescue
When a function returns an
Option<'T>, it may contain a value of type
T; it may not. You don’t know until you look into it. It’s Schrödinger’s cat! If the
Option is empty, we call it
None. If it is full, we call it
The advantage of using
Option is that now the compiler can help you out. You cannot assign an
Option<'T> to a variable of type
T. Take this example using
let opt = [1..4] |> List.tryFind (fun n -> n > 5) let n : int = opt // let n : int = opt;; // --------------^^^ // // This expression was expected to have type // int // but here has type // int option
So then, you cannot forget and accidentally assign a
null, only to have it bite you later. The compiler reminds you that you need to test the result before trying to use it:
let ns = [1..4] let none = ns |> List.tryFind (fun n -> n > 5) if none.IsSome then printfn "Found one greater than 5: %d" none.Value else printfn "None found greater than 5" // None found greater than 5 let some = ns |> List.tryFind (fun n -> n < 5) if some.IsSome then printfn "Found one less than 5: %d" some.Value else printfn "None found less than 5" // Found one less than 5: 1
Of course, you can override the safeguard, but at least then, you cannot claim ignorance:
let ns = [1..4] let none = ns |> List.tryFind (fun n -> n > 5) printfn "Found one greater than 5: %d" none.Value // System.NullReferenceException: // Object reference not set to an instance // of an object.
Next week, we will look at
Option some more to see how we can use it in a more functional fashion.