To see this, you need to realize that you are confusing symtoms with causes. A NullPointerException is a symptom. Failing to provide proper variable initialization is the cause. Your proposal eliminates the symptom and allows the cause to go undetected.

But silent errors are the most insidious errors of all! Failing to provide the right initialization of a variable, but letting the code proceed without crashing, is one such example. It is much better to crash, since then you know that there is a problem. You get that wonderful crashing behavior with Java objects, but not with primitives, which is unfortunate.

I see a contradiction between your calls for draconian error handling (which I heartily agree with) and your proposal here.

The only thing that Java needs reform of in default behavior is that there should be a convenient way to initialize primitive arrays.

Perhaps you misunderstood because I used a String object as example? Take then, for example, a method that will create and return an object only under certain circumstances and otherwise null. If you still think that would be ‘hypothetical’ I’d have to wonder…

We agree that overloading is terrible. However, you have not given one reason to support that your ’seperate flag’ is better than (or any different from) a null value for an object.

How would a flag indicating that an object was instantiated or not be any better or different than the null value that says the same thing?

- both need to be set
- both need to be checked

I concede that it may be possible to construct an example where there are multiple different states of a field not being filled in, for example if a user never saw it versus saw it and left it blank. But I’ll argue that trying to distinguish among these states by overloading a single field with values such as “”, ” “, and null is a bad implementation choice. Better to have a separate flag indicating the difference.

Regarding:
“Dozens of companies, hundreds of programs, and literally never in my life have I seen an application that differentiates between null and the empty string. ”
Simple case: Determine whether a string is given? If it is null, then it is not given, otherwise is it is, whether it is empty or not.
Can’t see what’s buggy about that.

how is “non-nullable string + boolean” more flexible than a “nullable string + null!=string”?

Simply because it has more possible values (i.e. num_possible_strings * 2 instead of num_possible_strings + 1). Granted that’s not necessarily super useful, but my point is that it’s at least as flexible.

“it could dramatically increase program robustness by eliminating an entire class of common errors.”

Or rather, “could dramatically DECREASE program robustness by HIDING an entire class of common errors.”

how is “non-nullable string + boolean” more flexible than a “nullable string + null!=string”?

The point is, in my 15+ years of programming, I have not once seen a case where such logic was necessary. Dozens of companies, hundreds of programs, and literally never in my life have I seen an application that differentiates between null and the empty string. (More precisely, I’ve seen hundreds of places where this is done, but in every case it has been a bug.)

As programmers we get too used to thinking about things in technical terms that have no meaning in the real world. Ask any non-programmer when they want a piece of data to be empty and when they want it to be null and you’ll get a blank stare. There is just no need for this distinction.

We tend to get bogged down in false notions of flexibility. For example, “since having null strings allows me more flexibility than not having it, we should keep it.” But this is misleading and pointless. Having a non-nullable string + a boolean is even more flexible than a nullable string, and MUCH less error-prone.

Having played with the JSR308 prototype (which includes the @NotNull/@Nullable annotations), I can say that I am deeply impressed with the work done by that group and excited to start using the annotations. It makes this discussion moot: If you don’t want nulls then don’t use them. And the 308 type checkers will make sure nobody does!

The underlying problem with NullPointerException isn’t that the variable ought to have a differet default value that we can use, but that the variable probably isn’t initialized due to a bug. Our code expects the variable to have a value; that’s why NullPointerException is thrown in the first place. If null is replaced by “” or whatever sensible default given the type we’re operating on, it might open up a whole can of worms.

As you write yourself, you need to check for equality to “default” — how’s that really different to checking equality to “null”? When that “if” statement is required either way, I think it’s better for the code to help you and throw a NullPointerException when you forget than just silently executing code that doesn’t do what it should.