If you are getting that many exceptions then you should step back and think
about the entire system. First, any exception logging mechanism should be
designed to be failsafe, meaning that if one logging mechanism fails there
should be a backup plan. This might be to log it to an alternate source, to
save the current log and then reset it, or it might be as simple as printing
out the message to the console. But you should do something, including
shutting down the system if conditions warrant.
But even more importantly, you should be asking why you are getting so many
exceptions that need to be logged, especially on servers. There may be many
problems occurring, both in design and in implementation. Exceptions are
*supposed* to be rare. Granted, over time exceptions will occur and tend to
accumulate, but if you are getting so many that you actually overwrite and
lose the original source of the problem then you may have a different sort
of problem. If one problem tends to trigger a cascading series of problems
so that you have a huge surge in a short period of time then you need to
design your error logging system with as care and effort as any other
mission critical piece of code, and relying on the plain-jane eventlog to
handle this is doomed - it was never intended to handle the load.
In short, you need to analyze the error handling system to determine its
requirements. If the standard system will not suffice then you need to
design a more robust error handling/logging system. It needs to be a first
class citizen in your product.
The eventlog is a great idea but it was not implemented as a mission
critical component; it is not a guaranteed mechanism.
"Leon Lambert" <la******@inil.com> wrote in message
news:Ob**************@TK2MSFTNGP10.phx.gbl...
You might reconsider putting you messages to the event log. This is what
we did and do with our large distributed application(s) and have had
several problems.
1) You can definitely make a system real sick to the point of crashing
if you fill up the event log and it isn't setup to over write older
messages.
2) You can loose the key critical message that caused the initial
problem because of all the cascading errors the happen because of it.
This is probably the most frustrating one. Makes you want to pull your
hair out when a customer calls with a problem and the real messages you
need to troubleshoot the problem has scroll out of the event log.
3) It sometimes a pain to get the customer to export the log so they can
send it to the developers to diagnose a problem.
In hind sight i think i would made my own error logger class (service)
and log to a text file. I would also make it fancy enough to also handle
code instrumenting. This would then log all internal state changes that
is useful for diagnosing problems. It needs to be fancy enough to
possibly handle creating archive files. So that it can compress and
archive log messages on some periodic rate. It would need to handle
issues to make sure the hard drive is not filled up with these files.
The customer just needs to email you these files then so you can use
them to diagnose problems. I really wish we had the time and budget to
redo our error handling this way.
The event log sounds like a quick and easy way to handle errors but
really isn't the best way to do this long term.
Hope this helps.
Leon Lambert
Kevin Jackson wrote: Let's say we log exceptions to the windows application event log using
the Exception Management Application Block. Is there a pattern that can be
used so the exception is logged only once and not everytime up through the
call chain? Is there anything a caller can key off of to check to see if it
should also log the exception?
