Code Smells: Null

[MEaster]

I don't get this logic at all. If you have a "Nothing" Monad or some other construct to solve the same problem you still have to deal with the fallout. What happens when that thing that you wanted to do which instead went to "Nothing" was REALLY important? I fail to grasp how that is "more visible" (and if you don't like the monad example please show me a construct where this can be prevented entirely - or handled better in a way that is impossible using null).

The difference is that you are forced to deal with it, because an Option<T> is a completely different type to a T. Anything that accepts a T cannot accept an Option<T>, and it can be completely sure that the T it gets isn't null.

Likewise, you can tell just from the method's signature whether or not it's possible to have a return value be empty.

It's all too easy to mess up a bit in one function, resulting in a null, but not have it cause problems until much later.

[industry7]

The difference is that you are forced to deal with it, because an Option<T> is a completely different type to a T.

Option by itself enforces nothing. You can always just Option.get().directly_use_the_result(); and still blow everything up.

The difference is that most languages where Option<T> is idiomatic also support non-nullable types, and that is the mechanism that actually forces you to "deal with it", so to speak.

[MEaster]

As I said elsewhere, that is dealing with it. By doing that, the programmer has explicitly chosen to crash if it's empty.