Re: Exception Logging in C#
From: Leon Lambert (lambertl_at_inil.com)
Date: 04/29/04
- Next message: Peter Row: "Re: newbie - can't use child namespaces without full qualification, eh?"
- Previous message: Bassem: "How to save image binary value to text or xml file."
- In reply to: Dave: "Re: Exception Logging in C#"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 29 Apr 2004 06:32:47 -0500
Obviously you have never working an a very large distributesd systems
doing things like soft realtime. Where you have hundreds of loosely
coupled applications doing level 2 to level 5 controls. Where many
different kinds of problems cascade up from lower level. These programs
are written by many groups of people around the world with many also
being written by third party customer consultants or the actual customer
himself. Until you have written an application system that takes many
multi-proccesor computer systems working in concert to perform a
customer solution i would not make comments like this. We have our own
logging system for the process alarms but used the event log for system
alarms. I still stick with my words that we should have also done our
own service for system alarms. Granted the event log might be ok for
small applications that don't produce many alarms but not really suited
for large applications.
Leon Lambert
Dave wrote:
> 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" <lambertl@inil.com> wrote in message
> news:ObEJwsRLEHA.2532@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?
>>>
>>>
>
>
>
- Next message: Peter Row: "Re: newbie - can't use child namespaces without full qualification, eh?"
- Previous message: Bassem: "How to save image binary value to text or xml file."
- In reply to: Dave: "Re: Exception Logging in C#"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
