dereferencing null

[Martin Nowak]

On Mon, 05 Mar 2012 23:31:34 +0100, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> 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

There are two independent discussions being conflated here. One about  
getting more
information out of crashes even in release mode and the other about
adding runtime checks to prevent crashing merely in debug builds.