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.
