dereferencing null

[Steven Schveighoffer]

On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 3/4/2012 11:50 PM, Chad J wrote:
>> Problems:
>> - I have to rerun the program in a debugger to see the stack trace.  
>> This is a
>> slow workflow. It's a big improvement if the segfault is hard to find,  
>> but only
>> a small improvement if the segfault is easy to find. Very bad if I'm  
>> prototyping
>> experimental code and I have a bunch to go through.
>
> I don't get this at all. I find it trivial to run the program with a  
> debugger:
>
>    gdb foo
>    >run
>
> that's it.

This argument continually irks me to no end.  It seems like the trusty  
(rusty?) sword you always pull out when defending the current behavior,  
but it falls flat on its face when a programmer is faced with a Seg Fault  
that has occurred on a program that was running for several days/weeks,  
possibly not in his development environment, and now he must run it via a  
debugger to wait another several days/weeks to (hopefully) get the same  
error.

Please stop using this argument, it's only valid on trivial bugs that  
crash immediately during development.

I wholeheartedly agree that we should use the hardware features that we  
are given, and that NullPointerException is not worth the bloat.  But we  
should be doing *something* better than just printing "Segmentation Fault".

-Steve