Non-null objects, the Null Object pattern, and T.init

[Walter Bright]

On 1/17/2014 4:25 PM, Andrei Alexandrescu wrote:
> On 1/17/14 4:21 PM, Adam D. Ruppe wrote:
>> On Saturday, 18 January 2014 at 00:12:16 UTC, Andrei Alexandrescu wrote:
>>> Yes, improving the language is in the cards. I have collected enough
>>> hard evidence to convince myself that null references are a real and
>>> important issue (previously I'd agreed with Walter who is considering
>>> it not particularly remarkable).
>>
>> Have they tried using a NotNull!T yet?
>
> Not a D project (Java/Android). However there is work underway on a static
> analyzer for Java. I cannot give exact stats, but we have gathered extensive
> data that null pointer exceptions form a major, major problem on Facebook's
> Android app, and that virtually all can be solved by static analysis.
>
> No amount of speculation and hypothesizing will talk me out of that.

I don't disagree that some form of static analysis that can detect null 
dereferencing at compile time (i.e. static analysis) is a good thing. I concur 
that detecting bugs at compile time is better.

I don't disagree that for an app like a game, soldiering on after the program is 
in an invalid state doesn't do any particular harm, and so one can make a good 
case for using the null object pattern.

I do not agree with the notion that null pointers detected at runtime are harder 
to track down than other kinds of invalid values detected at runtime.

I strong, strongly, disagree with the notion that critical systems should 
soldier on once they have entered an invalid state. Such is absolutely the wrong 
way to go about making a fault tolerant system. For hard evidence, I submit the 
safety record of airliners.