dereferencing null

[Chad J]

On 03/03/2012 02:06 PM, Walter Bright wrote:
> On 3/3/2012 2:13 AM, bearophile wrote:
>> Walter:
>>
>>> Adding in software checks for null pointers will dramatically slow
>>> things
>>> down.
>>
>> Define this use of "dramatically" in a more quantitative and objective
>> way,
>> please. Is Java "dramatically" slower than C++/D here?
>
> You can try it for yourself. Take some OOP code of yours, and insert a
> null check in front of every dereference of the class handle.

I have a hard time buying this as a valid reason to avoid inserting such 
checks.  I do think they should be optional, but they should be 
available, if not default, with optimizations for signal handlers and 
such taken in the cases where they apply.

Even if it slows my code down 4x, it'll be a huge win for me to avoid 
this stuff.  Because you know what pisses me off a helluva lot more than 
slightly slower code?  Spending hours trying to figure out what made my 
program say "Segmentation fault".  That's what.

I hate hate HATE vague error messages that don't help me.  I really want 
to emphasize how super dumb and counterproductive this is.

If I find that my code is too slow all of a sudden, then let me turn off 
the extra checks.  Otherwise, I expect my crashes to give me some 
indication of what happened.

This is reminding me that I can't do stuff like this:

class Bar
{
	int foo;
}

void main()
{
	Bar bar;
	try {
		bar.foo = 5;
	} catch ( Exception e ) {
		writefln("%s",e);
	}
}

DMD 2.057 on Gentoo Linux, compiled with "-g -debug".  It prints this:
Segmentation fault

Very frustrating!
(And totally NOT worth whatever optimization this buys me.)