Null Considered Harmful

The best solution I've seen is a Maybe Monad.<p>The problem is that unless your language has support baked in (a la Haskell) the syntax has way too much overhead.<p>If you haven't played with Haskell, I thought this was a pretty good explanation: <a href="http://paulbarry.com/articles/2009/07/17/emulating-haskells-maybe-in-java-with-checked-exceptions" rel="nofollow">http://paulbarry.com/articles/2009/07/17/emulating-haskells-...</a>

Is he really suggesting to replace all attempts to dereference null with no-ops? Weird.<p>I think there are two ways to deal with this. Either it is known at compile time that a particular variable must never be null. In that case the compiler should catch it like it does with C++ references.<p>If the decision is left until runtime, the only way to deal with it is to specify or compute a default value, which is very much complicated by the special cased 'this' parameter in OO languages.<p>It's kind of funny that basically everything Java has removed from C++ turns out to be important for a statically typed language. Java should have been a C++ virtual machine with garbage collection.

Strange. Nulls, as the author describes them, are incredibly useful. Being able to test for existence and branch accordingly saves us a ton of extra ".IsNull" properties that we'd otherwise need to tack on to every class so that we could tell whether we were looking at a real instance, or just a dummy that the compiler initialized without asking.<p>His 'solution' to the Null Pointer Exception trades that easy to identify and fix runtime error for an entire class of subtle logic errors that are pretty much guaranteed to arise when you have a bunch of improperly-initialized-yet-alive objects sprouting up every time you declare them.<p>No thank you.<p>My suggestion is to use an IDE that notices potential Null Pointer Exceptions for you and lets you know about them. VS.NET does this, as does every Java IDE worth its salt. This is simply not an issue if you use modern tools. Please don't go adding language features to "fix" a problem that went away ten years ago.

Part of the problem is that NULL is used to convey meaning. e.g. "login" returns NULL if the user isn't logged in.<p>So NULL can mean dozens of things. You can return something more valid (e.g. "Guest", or even "NotApplicable"), but doesn't get rid of the checks... Can result in more readable code though.<p>This is a good reference too: <a href="http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare" rel="nofollow">http://www.infoq.com/presentations/Null-References-The-Billi...</a> Edit: Plus there is a discussion on this talk here: <a href="http://lambda-the-ultimate.org/node/3186" rel="nofollow">http://lambda-the-ultimate.org/node/3186</a>

In my experience NPE is the most common java exception and a huge waste of programmer time.

I almost never have null pointer exceptions. I adhere fairly strongly to Design By Contract, which means that I check for boundary conditions (null being the most comon) at method and constructor entry points and throw exceptions there and then. This means nulls are caught early rather than late (as <i>parameters</i>, rather than as <i>state</i>) and so the cause can be found right then and there.<p>NPE as a "problem" is vastly overrated. Just apply DBC wisely.

I fail to see the problem: A NPE is thrown if the code tries to access an object, but there's no object.Using a standard behavior here would conceal that there's a flaw in the program logic.

Nulls are often used to signify that an object can't be returned for some reason, often not actually worth an exception. (Hence null is actually a valid result).

This article is like a fiction the "Java Land". To the Java language designers, it would be like a space-age concept.