Null references redux

[Ary Borenszweig]

Walter Bright wrote:
> 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.

Null pointer seg faults *not being able to happen* are much more safe. :)