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