Null references redux

Tom S h3r3tic at remove.mat.uni.torun.pl
Sat Sep 26 20:26:49 PDT 2009


Jeremie Pelletier wrote:
> Ary Borenszweig wrote:
>> 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. :)
> 
> There is no such thing as "not being able to happen" :)
> 
> Object thisCannotPossiblyBeNullInAnyWayWhatsoever = cast(Object)null;
> 
> I seem to be the only one who sees Walter's side of things in this 
> thread :o)
> 
> For nonnulls to *really* be enforcable you'd have to get rid of the cast 
> system entirely.

It's a systems programming language. You can screw up the type system if 
you really want to. But then it would still fall back to the lovely 
segfault. If you don't screw with it, you're safe with static checking. 
It's a clean win.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode



More information about the Digitalmars-d mailing list