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

Walter Bright newshound2 at digitalmars.com
Fri Jan 17 19:11:16 PST 2014


On 1/17/2014 6:48 PM, Andrei Alexandrescu wrote:
> On 1/17/14 5:05 PM, Walter Bright wrote:
>> On 1/17/2014 4:17 PM, Andrei Alexandrescu wrote:
>>>> Even if you got rid of all the nulls and instead use the null object
>>>> pattern, you're not going to find it any easier to track it down, and
>>>> you're in even worse shape because now it can fail and you may not even
>>>> detect the failure, or may discover the error much, much further from
>>>> the source of the bug.
>>>
>>> How do you know all that?
>>
>> Because I've tracked down the cause of many, many null pointers, and
>> I've tracked down the cause of many, many other kinds of invalid values
>> in a variable. Null pointers tend to get detected much sooner, hence
>> closer to where they were set.
>
> I'm not sure at all. Don't forget you have worked on a category of programs for
> the last 15 years. Reactive/callback-based code can be quite different, as a
> poster noted. I'll check with the folks to confirm that.

We've talked about the floating point issue, where nan values "poison" the 
results rather than raise a seg fault. I remembered later that a while back Don 
tried to change D to throw an exception when a floating point nan was 
encountered, specifically because this made it easier for him to track down the 
source of the nan. He said it was pretty hard to backtrack it from the eventual 
output.

In any case, I'm open to data that supports the notion that delayed detection of 
an error makes the source of the error easier to identify. That's not been my 
experience, and my intuition also finds that improbable.


> The larger point I'm trying to make is your position and mine requires we need
> to un-bias ourselves as much as we can.

I agree with that. So I await data :-)


More information about the Digitalmars-d mailing list