Re: [GD-General] runtime error logging

[Colin F. <cp...@ea...>]

I like the idea of hashing error strings, collapsing identical
error messages in to a single instance.  Thus, the time stamp
should not be part of the error text message; it should be
stored along with the error, and should be "printed" alongside
the error text upon display and/or logging to a file.

I like the idea of having flags associated with messages,
such as priority, and basic nature.

I think the error logging mechanism should have settings
to allow filtering out messages based on priority.  Also,
the user should be able to control which kinds of messages
are subject to "collapsing via hashing".

If you do collapse any messages, for sure I think you should
COUNT the number of collapsed incidents.  I think it would
be illuminating to see that an error message occurred exactly
706 times (perhaps the number of keystrokes, resource files,
seconds elapsed, visible objects, etc), or just one time, or
1,000,000 times!

Finally, I think you should store a run-length encoded 
vector of the error hash values.  It should be possible
for you to recover the temporal order of all error messages.

I was considering allowing myself to suppress specific 
error messages from appearing on a console in my game,
dynamically.  I would type: "hide error 17", or simply
right-click on the error and select "hide".  Thus, the
console would not be cluttered by future instances of
"error 17".

I suppose an upper limit on the log file / error log file
size is a good idea, or some policy about what to do when
a certain size is reached.

I guess I haven't really run in to many situations in which
the number of error / status messages has swamped me -- but I've
heard of a single, persisting error condition (network down,
out of disk space, out of memory, etc) leading to all available
disk space being used to repeatedly log the same error.
It is really ironic when the huge log file leads to errors 
that also need to be logged, thus leading to endless silly
log messages.  It's as nutty as an exception handler doing
something ambitious, like launching a window to report the
error, causing another out-of-memory exception!  At that
point your app is doubly-insane.

--- Colin

cp...@ea...