Okay, I realise this is probably a naïve question, but it hasn't been answered by any of the anti-null articles.<p>Usually, null as a return value has some kind of special meaning, like indicating a failure or other edge case. Making null go away doesn't mean that case can't happen, you just need to handle it differently. The example in the article<p><pre><code> String com = tld("example").getOrElse("unknown");
</code></pre>
is one of those lovely academic examples which is completely out of touch with reality. Unless you're doing nothing but displaying it to the user, the string "unknown" is just as bad as the null object in almost every way, and worse in others: there's a reasonable chance that "unknown" will one day be a valid TLD.<p>So the proposed solution with the Option<> generic type really is just a reminder to the programmer. There's no technical advantage. You might even see a decrease in performance if the compiler can't optimise it away.<p>Except we already have a reminder mechanism: checked exceptions. Remember those? Remember how popular they are?<p>C# actually has this concept of nullable types. It doesn't apply to class types which are always nullable, but structs (with mostly value semantics as opposed to identity semantics) can be either nullable or not - just like C/C++'s passing by value I suppose. Except they're so unwieldy to use due to the <i>OMG IT MIGHT BE NULL</i> paranoia (you can't do anything as ridiculous as <i>access a member</i> without unboxing... which will throw a NullPointerException if null - score!), you may as well redefine your struct as a class and use that. (which breaks cases where you didn't want it nullable. score 2!)<p>I won't even treat C++ references (&) as a realistic attempt at a non-nullable type system because safety and C++ don't go together anyway. [1] I've not used scala, so if someone has a good, realistic example of code where scala's non-null system works well, I'd love to see it.<p>I guess I have to add that I actually <i>liked</i> static typing for a long time (I've done my stereotypical 10000 hours of C++), until I noticed I was just slowing myself down and my code in dynamic languages wasn't any worse, just quicker/easier to modify. Is this a sign of programming maturity? Is static typing the "training wheel" mechanism for beginning programmers? I'm starting to think so.<p><pre><code> [1] void bar(Foo& f); Foo* p = 0; bar(*p);</code></pre>
I agree with the author that having an option datatype makes the intention "this method returns some Foo or nothing" clear.<p>However, the suggested encoding of an option type in Java blends poorly with subtyping because a JOption<MySubtype> is not a subtype of JOption<MySupertype>. For a quick optional-return scenario, it may work, but as a substitute for nulls in optional parameters, you'd have to remember the precise type of every parameter and create non-empty JOption instances in a rather verbose way.<p>As an alternative, you could use a tool like Findbugs and its @Nullable annotation.
Null is an element of any given set. So it's natural enough. Maybe the way we human use it in implementations is wrong. But after all Null is defined by human anyway.<p>"...And you, as a consumer of that method, need to check every time if the return value is Null. If you don’t – you (usually) get a Null pointer exception and your program crashes."<p>Can't this be handled by the language itself, by default?