Spec#, nullables and more

Walter Bright newshound2 at digitalmars.com
Sat Nov 6 14:08:27 PDT 2010


bearophile wrote:
> Gary Whatmore:
> 
>> You're missing the point. The reason for seg faults is to terminate the
>> application as quickly as possible. The developer then fires up the
>> debugger and fixes the app. Seg faults should never happen in production
>> code. You only release when all seg faults are fixed. The builtin unit
>> tests in D can guarantee this with 100% test coverage.
> 
> Unittests help remove and avoid some bugs, but experience shows they don't
> solve/avoid all problems. Null exceptions do happen in production code. 100%
> coverage of unittests can't avoid all possible bugs, because it's easy to
> miss some code paths in unittests. Take a look at bugzilla to see many basic
> bugs in Phobos despite the usage of unittests.

Do a:

    make -cov

in the phobos directory, which will run the coverage analyzer on all the unit 
tests in the library. You'll find that the coverage is nowhere near 100%.

Granted, even 100% coverage is no guarantee of no seg faults, but in practice it 
is very effective.

And finally, null exceptions are not a bug. They are the messenger that there is 
a bug in the code. Until one knows why a null pointer was dereferenced, one 
cannot conclude that the existence of the null pointer was the bug.


More information about the Digitalmars-d mailing list