Null references (oh no, not again!)

[Ary Borenszweig]

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.