Customizing Dolphin Virtual Machine Dump Report

Is it possible to customize the output of the .ERRORS file?  I want to
include such things as a windows version ( including service pack
information ) and MS Office version and my own application version.  (
ok, generally arbitrary information as I see fit to report )...

Is this easy?   I assume I'd be subclassing some Stack-Writer type class
( although I can't seem to find anything mentioning 'Dolphin Virtual
Machine Dump Report" anywhere to give me pointers on where to look.

Anyone?

"Mark Derricutt" <[hidden email]> wrote in message
news:ckeneh$[hidden email]...
> Is it possible to customize the output of the .ERRORS file?  I want to
> include such things as a windows version ( including service pack
> information ) and MS Office version and my own application version.  ( ok,
> generally arbitrary information as I see fit to report )...

I am not sure if this is the best way, but I found an approach that allows
me to easily add any info I want at the top of a crash dump.  Override the
method logError: on the instance side of your application's SessionManager
subclass.  See the example bellow.  It just occurred to me that you may want
to have some additional error trapping incase it can't write to the file for
some reason.

===========
logError: anError
"cdemers - 9/10/2004 Write the program version to the error log."
| fs |
fs := FileStream write: self imagePath , '.errors' mode: #append.
fs nextPutAll: 'Version ' , self class versionString , ' ' , self class
versionDate displayString; cr.
fs close.
super logError: anError
===========

Chris

"Mark Derricutt" <[hidden email]> wrote in message
news:ckeneh$[hidden email]...
You can't modify the crash dump output, because it is produced by the VM.
However actual crashes are very unusual, and it is far more likely that you
will get unhandled Smalltalk exceptions in your applications. These are
handled by the runtime SessionManager, ending up in
SessionManager>>unhandledException:. The default implementation of this in a
GUI application logs the error (sends it to SessionManager>>logError:) and
then pops a warning/error message box which allows the user to continue (if
a resumable exception such as a Warning or resumable Error), or "abort".
Aborting in a GUI session means terminating the current event/command, but
the application continues to run. This is useful because it means that bugs
in particular areas of your application do not cause the whole application
to fail. In a console application the program exits - the distinction here
being that a GUI application is event driven and so it is only the current
event that experienced an error, whereas a console application is considered
to be performing a batch operation that runs sequentially from start to end.
Of course one is free to do different things in one's own session manager
classes.

As for error logging, well recall that the errors end up in
SessionManager>>logError:. The default behaviour is to use the VM's dump
capability to produce the error log. This is useful because the VM dump
includes a standard set of information that can be very useful in
determining the cause of errors, however it is quite large and since one
typically encounters a lot of unhandled errors during the development
process DevelopmentSessionManager overrides this  to write a simpler dump of
the callstack to the .errors file being performed by code in the image (see
DevelopmentSessionManager>>logError:). If you want to do your own error
logging you can either supplement the VM dump by appending (or prepending)
additional information, or you can replace the VM dump altogether by
overriding SessionManager>>logError: as DevelopmentSessionManager does.

Regards

Blair

Blair,

> You can't modify the crash dump output, because it is produced by the VM.

Have you looked at Ghoul?  Anything you can do to help it along would be
great for those rare occaisions when Dolphin or a deployed exe does take
a hit.

One suggestion for Ghoul would be to take input from the clipboard as
well as files.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]