Spec#, nullables and more

[Roman Ivanov]

On 11/5/2010 10:27 AM, Don wrote:
> Pelle Månsson wrote:
>> On 11/05/2010 03:04 PM, Kagamin wrote:
>>> Pelle Månsson Wrote:
>>>
>>>> Getting the error early is actually a lot better than getting the error
>>>> late.
>>>
>>> OK, but it doesn't reduce the number of bugs. You had an error with
>>> nullables and you still has error with non-nullables.
>>
>> But in the non-nullable version you actually know where the bug is,
>> namely where you assign the null to the thing that shouldn't be null.
>> The segfault can come from any unrelated part of the program whereto
>> your null has slipped, at any later point in time.
> 
> I've always found it very easy to work out where a null came from. 

I hadn't. It really depends on what kind of code you're dealing with.
I've seen null-related bugs that took many, many hours to trace, because
the code was using several third-party libraries.

For example, library A can return a null in some obscure case without
documenting that behavior. Library B can interpret null as a meaningful
value and try to do something. You code sits in between, does some logic
and passes information from A to B.

Stuff like that is _very_ difficult to debug, and having non-nullable
types would make it much, much easier.

> What
> I would hope from a non-nullable type is to eliminate rare code paths
> where a null can occur, which might not show up in testing.