Null references redux

[Walter Bright]

Daniel Keep wrote:
> "But the user will just assign to something useless to get around that!"
> 
> You mean like how everyone wraps every call in try{...}catch(Exception
> e){} to shut the damn exceptions up?

They do just that in Java because of the checked-exceptions thing. I 
have a reference to Bruce Eckel's essay on it somewhere in this thread. 
The observation in the article was it wasn't just moron idiot 
programmers doing this. It was the guru programmers doing it, all the 
while knowing it was the wrong thing to do. The end result was the 
feature actively created the very problems it was designed to prevent.


> Or uses pointer arithmetic and
> casts to get at those pesky private members?

That's entirely different, because privacy is selected by the 
programmer, not the language. I don't have any issue with a user-defined 
type that is non-nullable (Andrei has designed a type constructor for that).


> If someone is actively trying to break the type system, it's their
> goddamn fault!  Honestly, I don't care about the hacks they employ to
> defeat the system because they're going to go around blindly shooting
> themselves in the foot no matter what they do.

True, but it's still not a good idea to design a language feature that 
winds up, in reality, encouraging bad programming practice. It 
encourages bad practice in a way that is really, really hard to detect 
in a code review.

I like programming mistakes to be obvious, not subtle. There's nothing 
subtle about a null pointer exception. There's plenty subtle about the 
wrong default value.


> And what about the people who AREN'T complete idiots, who maybe
> sometimes just accidentally trip and would quite welcome a safety rail
> there?

Null pointer seg faults *are* a safety rail. They keep an errant program 
from causing further damage.


> Finally, let me re-post something I wrote the last time this came up:
> 
>> The problem with null dereference problems isn't knowing that they're
>> there: that's the easy part.  You helpfully get an exception to the
>> face when that happens. The hard part is figuring out *where* the
>> problem originally occurred. It's not when the exception is thrown
>> that's the issue; it's the point at which you placed a null reference
>> in a slot where you shouldn't have.

It's a lot harder to track down a bug when the bad initial value gets 
combined with a lot of other data first. The only time I've had a 
problem finding where a null came from (because they tend to fail very 
close to their initialization point) is when the null was caused by 
another memory corruption problem. Non-nullable references won't 
mitigate that.