dereferencing null

Steven Schveighoffer schveiguy at yahoo.com
Mon Mar 5 18:04:20 PST 2012


On Mon, 05 Mar 2012 20:17:32 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

>
> 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?

It depends on the OS facilities and the installed libraries for such  
features.  It's eminently possible, and I think on Windows, you can catch  
such exceptions too in external programs to do the same sort of dumping.   
On Linux, you get a "Segmentation Fault" message (or nothing if you have  
no terminal showing the output), and the program goes away.  That's the  
default behavior.  I think it's better in any case to do *something* other  
than just print "Segmentation Fault" by default.  If someone has a way to  
hook this in a better fashion, we can include that, but I hazard to guess  
it will not be on stock Linux boxes.

> 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.

Certainly for Mac OS X, it should do the most informative appropriate  
thing for the OS it's running on.  Does the above happen for D programs  
currently on Mac OS X?

Also, I don't think an exception is the right thing in any case -- it may  
not actually get caught if the Seg Fault is due to memory issues.  I'd  
rather the program do it's best attempt to print a stack trace and then  
abort.

-Steve


More information about the Digitalmars-d mailing list