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