Null references (oh no, not again!)

[Ary Borenszweig]

Ary Borenszweig wrote:
> Walter Bright escribió:
>> Ary Borenszweig wrote:
>>> Walter Bright escribió:
>>>> Ary Borenszweig wrote:
>>>>> Walter Bright escribió:
>>>>>> Ary Borenszweig wrote:
>>>>>>> It's not like that. They don't require you to initialize a 
>>>>>>> variable in it's initializer, but just before you read it for the 
>>>>>>> fist time. That's very different.
>>>>>>
>>>>>> The only way to do that 100% reliably is to instrument the running 
>>>>>> code.
>>>>>
>>>>> Java does it on compile time.
>>>>
>>>> Java is a severely constrained language. Even so, how does it do 
>>>> with this:
>>>>
>>>> Foo f;
>>>> if (x < 1) f = new Foo(1);
>>>> else if (x >= 1) f = new Foo(2);
>>>> f.member();
>>>
>>> Whenever there are branches in code and a variable still doesn't have 
>>> a value at that point:
>>>  - if all branches assign a value to that variable, from now on the 
>>> variable has a value
>>>  - if not, at then end of the branches the variable still doesn't 
>>> have a value
>>
>> That rule gets the wrong answer in the above case. Consider that in 
>> order to get where you want to go with this, the flow analysis has to 
>> always work, not most of the time work. Otherwise you get bug reports 
>> with phrases like "seems to", "sometimes", "somehow", "I can't figure 
>> it out", "I can't reproduce the problem", etc.
>>
>> Here's another lovely case:
>>
>> Foo f;
>> if (x < 1) f = new Foo();
>> ... lots of code ...
>> if (x < 1) f.member();
>>
>> The code is quite correct and bug-free, but flow analysis will tell 
>> you that f in f.member() is "possibly uninitialized".
> 
> That's exactly the example of a code with a possible bug that'll get an 
> null pointer access. Imagine in "... lots of code ..." you use f and the 
> compiler complains. But you are sure "x < 1" will be true! Then you need 
> to add an else and some assert(false) or throw an exception and that's it.
> 
> If the second condition is "if (x >= 1)" and in the next line you use f, 
> then yes, you are definitely sure that "f" is initialized if you didn't 
> touch "x" in "... lots of code ...". Well... not really, if some other 
> thread changed "x" in the middle of the code, then you are not really 
> sure about that. So again, it's an error.
> 
> If you are really, really sure that this won't happen, you do:
> 
> Foo f = null;
> 
> and that's it. You make the compiler help you only when you want it to, 
> and that'll be most of the time.
> 
> The same goes with:
> 
> Foo f;
> bar(&f);
> 
> If you are sure that bar will assign a value to f if it doesn't have 
> one, go ahead and initialize "f" with null.

By the way, I'm defending this functionality because I received the 
"variable might not be initialized" errors many times now, and I know my 
coworkers also received them many times. In those cases, we were always 
making a mistake. I can't remember even one time when I had to put a 
dummy initializer in a variable just to make the compiler happy.