(non)nullable types

[Christopher Wright]

Jarrett Billingsley wrote:
> On Wed, Feb 11, 2009 at 3:40 PM, Christopher Wright <dhasenan at gmail.com> wrote:
>> Your language features should get rid of bugs that are easy to make and
>> difficult to track down. It's not worthwhile to alter your language to
>> remove easily found, easily fixed bugs.
> 
> Except when someone passes a null reference into a large, complex data
> structure and that reference is passed around blindly and never
> dereferenced until somewhere far down the line, giving you a segfault
> in a program location that you never would have expected.  By then
> it's much more difficult to figure out where that null reference came
> from.  I've had a much larger share of these kinds of null reference
> errors than the "oops someone passed a null into my function and I
> didn't account for it" kind.  Disallowing null references on most
> public interface functions from the beginning would make those kinds
> of bugs nonexistent.
> 
> Otherwise, you have to put explicit runtime null checks on every
> public interface function, and woe to the guy who forgets to do that.

Or add an invariant. You know which field is null when it shouldn't be, 
so that should be simple enough. Or use a property rather than a field 
and add a contract.

This covers the same cases that non-nullable types do, though admittedly 
with slightly less granularity.

A complex datastructure might have a complex initialization process that 
is best spread across a few lines of code rather than happening all at 
once. If that is the case, you *can't* use non-nullable types, because 
that restriction isn't valid until the object is fully initialized. But 
you can still use contracts here.