On 5/19/13 1:12 PM, Idan Arye wrote:
On Sunday, 19 May 2013 at 13:13:07 UTC, Andrei Alexandrescu wrote:
On 5/19/13 9:11 AM, deadalnix wrote:
On Sunday, 19 May 2013 at 13:08:53 UTC, Andrei Alexandrescu wrote:
Sounds like a race problem unrelated to null. With non-null objects
the race would have manifested itself in a different way, perhaps even
more pernicious.


It is both a race condition and a null problem.

No, it's just a race condition.

And having non nullable
type would have been a compile time error instead of days of debugging.

No, the race condition would have stayed.


Andrei

I believe this claim requires an explanation:

It's a good practice to initialize references(and all other types of
variables) as soon as possible - and if possible, right away in the
declaration. If that reference started as null, it's safe to assume it
was not possible to initialized it at declaration, so it was
intentionally initialized with null(if there was no initialization Java
would scream at you).

Now, let's assume that reference was non-nullable. It is safe to assume
that this change would not remove the obstacle that prevented that
reference from being initialized right away in the declaration - so you
still need to initialize it to something else - let's call that
something `Nil`. Nil is an object that tells you that the reference has
not yet been initialized.

So, in the original bug the reference "could be seen
as null where it was assumed everywhere to be set.". But now we don't
have null - so that piece of code that thought the reference is null
would now think that it is... what? The initialization value? No!
Because we didn't switch from initializing the reference with null to
initializing it with the later initialization value - we couldn't do it.
Instead, we had to use Nil. So now, the reference 'could be seen as Nil
where it was assumed everywhere to be set'...

Now, if you are lucky and your Nil is the better-kind-of-null that is
used in dynamic object oriented languages, you'll get a nil exception -
which is just as good as null exception. But if you are not so lucky,
and you had to declare Nil as a blank object of the type of that
reference, you are going to have logical bug, which is far worse than
exceptions...

So the race would have manifested it just the same, except under the name of Nil instead of null.

Andrei

Reply via email to