Lints, Condate and bugs

[Roman Ivanov]

On 10/28/2010 1:40 PM, Walter Bright wrote:
> Don wrote:
>> With the bugs I've fixed in the DMD source, I've seen very many cases
>> of 7, several cases of 2 and 6, and only one case of 8.
>> Many bugs are also caused by dangerous casts (where a pointer is cast
>> from one type to another).
>> But almost everything else been caused by a logic error.
>>
>> I am certain that there are still many null pointer bugs in DMD.
> 
> None of the null pointer bugs dmd has had would have been prevented by
> using non-nullable types. I.e. they were not "I forgot to initialize
> this pointer", but were instead the result of logic errors, like running
> off the end of a list.

Preventing bad initializations at compile time is not the only benefit
of non-nullable types worth considering.

They would be a great help in debugging programs, for example.
NullPointerException is probably the most common error I see in Java.
95% of all times it gets thrown in some weird context, which gives you
no idea about what happened. The result is a long and tedious debugging
session.

Here is a common case:

String name = Config.get("name"); //returns null, no error
//...
if (name.length() > 0) { //NullPointerException!

The problem is that the second line could be reached after executing
hundreds of lines of (unrelated) code. The null could be passed around,
propagated through method calls. The exception could even be thrown from
a deeply nested call in a third party library. Stuff like that is common
and really difficult to debug.

With non-nullable types, the exception will be thrown on the first line
(where assignment happens), making it obvious, which piece of code is at
fault and potentially saving hours of programmer's time.

Another benefit of non-nullable types is that they can serve as a form
of documentation, making intent behind the code clearer, and making the
code easier to read:

Old Java:
if (myString != null && !myString.equals(""))

C#:
if (!String.IsNullOrEmpty(myString))

Could be:
if (myString != "")

> NULL in dmd represents "this datum has not been computed yet" or "this
> datum has an invalid value" or "this datum does not exist". With
> non-nullable types, they'd have to be set to a datum that asserts
> whenever it is accessed, leading to the same behavior.
> 
> Having the program abort due to an assert failure rather than a segment
> violation is not the great advance it's sold as. I think one should
> carefully consider whether a particular null pointer problem is a
> symptom of a logic bug or not before claiming that eliminating null
> pointers will magically resolve it.
> 
> Otherwise, you're just shooting the messenger.