Spec#, nullables and more

dennis luehring dl.soluz at gmx.net
Fri Nov 5 08:06:14 PDT 2010


Am 05.11.2010 15:27, schrieb Don:
> 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. 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.

or better -> "how many UNTESTED null-able situations out there?" i think 
an enormous amount of code that just explodes when an null runs through it

good example is c# - because of (nearly) everything is nullable in c#
is see code like if( x != null ){ if( y != null ){ if( blub != null ... 
checks all day long, and if i don't see code like this does not mean 
that it is safer then...






More information about the Digitalmars-d mailing list