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.
