dereferencing null

[Michel Fortin]

On 2012-03-05 22:31:34 +0000, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

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

Walter's argument about using gdb doesn't make sense in many scenarios. 
He's probably used a little too much to programs which are short lived 
and have easily reproducible inputs (like compilers).

That said, throwing an exception might not be a better response all the 
time. On my operating system (Mac OS X) when a program crashes I get a 
nice crash log with the date, a stack trace for each thread with named 
functions, the list of all loaded libraries, and the list of VM regions 
dumped into ~/Library/Logs/CrashReporter/. That's very useful when you 
have a customer experiencing a crash with your software, as you can ask 
for the crash log. Can't you do the same on other operating systems?

Whereas if an exception is thrown without it being catched I get a 
stack trace on the console and nothing else, which is both less 
informative an easier to lose than a crash log sitting there on the 
disk.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/