• steveh <steveh57 useshotmai.l> Nov 06 2010
• bearophile <bearophileHUGS lycos.com> Nov 06 2010
• Walter Bright <newshound2 digitalmars.com> Nov 07 2010

steveh <steveh57 useshotmai.l> writes:

bearophile Wrote:

 Walter:
 
 I don't see that non-null is such a special case that it would benefit from a 
 special case syntax.


 Well, nonnull are a special cases because:
 - There is a good enough way to solve this problem. This is not true in the
general case.
 - null exceptions are very common bugs, among the most common ones in Java and
C#.


citation needed. I've made software with 100% line and path coverage. No
segfaults happened ever. Spent enormous time optimizing the code and its
quality. In quality applications NPE/segfaults simply don't exist.

bearophile <bearophileHUGS lycos.com> writes:

steveh:

 citation needed. I've made software with 100% line and path coverage. No
segfaults happened ever. Spent enormous time optimizing the code and its
quality. In quality applications NPE/segfaults simply don't exist.


You are right, some citation is needed. I have seen or read many papers that
talk about facing the null problem (I can list them if you want), but hard data
is always not easy to find.

And by the way, I believe you. Bugs that manifest themselves through a null
exception are probably the most common in Java code, but they aren't the harder
to fix. Concurrency bugs are far harder to fix (or even to find) than null
pointer exceptions. This thread is not about ways to avoid concurrency bugs (D
uses message sending to avoid some concurrency bugs).

Bye,
bearophile

Walter Bright <newshound2 digitalmars.com> writes:

bearophile wrote:
 Concurrency bugs are far harder to fix (or even to find) than
 null pointer exceptions. This thread is not about ways to avoid concurrency
 bugs


The hardest problems are concurrency issues, followed by memory corruption.