How would functional programming help you in this department?
In C#, null is just one possible value of the regular type Foo. The compiler cannot tell whether you have started returning null where you previously only returned non-null values, nor can it tell whether you've handled those null values correctly at the consumption site.
In F#, None is a subtype of the Option<Foo> union type, which is different from the plain Foo type and from the other subtype Some Foo. If you change a function that used to return a plain Foo into one returning Option<Foo>, every place in your code where that function is consumed will throw a compile error until you edit it to unwrap and handle the distinct Some Foo and None subtypes.
Re:Why Isn’t F# the King of .NET?
by actsasbuffoon on Monday September 19, 2016 @11:00AM
(#12531915)
Many functional programming languages have stronger type systems than C#. They typically don't accept null as a valid substitute for any type. To represent a nullable type, you wrap the value in a generic container. Think of it as being like an array that contains at most 1 item.
The interface of this generic container only allows you to interact with the (potentially) wrapped value in a way that is type safe. That doesn't completely eliminate having to think about how the business logic should differ for missing values, but it ensures that you'll never get a null pointer exception.
I can imagine that in f# this refactor would be a lot simpler and would allow me to have a case of empty that I could propagate around and handle transparently.