On Mon, 05 Mar 2012 20:17:32 -0500, Michel Fortin
<michel.for...@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
