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 string
!
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 you need to represent the idea that a function may not return a result, use F#’s Option
. You can think of an Option
as a bucket (pronounced BUCK-et, not boo-KAY):
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 Some
.
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 List.tryFind
:
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.
2 replies on “F# Friday – The Option Type, Part 1”
[…] F# Friday – The Option Type, Part 1 – Brad Collins […]
[…] Last week we introduced the Option type as a way of representing when a function may or may not return a value. […]