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