467,886 Members | 1,790 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,886 developers. It's quick & easy.

Exception Logging in C#


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?
Nov 16 '05 #1
  • viewed: 9448
Share:
6 Replies
I don't know of anything in the base exception object itself that you can
use to uniquely identify an exception object but if all your exceptions are
custom objects you can add a field that uniquely identifies it (e.g. Guid or
a bool) to keep track of the logged exceptions.

Even if you can do that I don't recommend it. One of the benefits of the
exception model is that it allows catch blocks to catch-wrap-throw an
exception, each time adding more context information. This provides a much
richer and more meaningful error message to be presented to the user. I'd
prefer to have it logged at the initial site of the exception (to make sure
that at least one record of it is kept), and then once again at the
component boundary (e.g. before it gets thrown across a web service). If the
exception gets caught and handled or swallowed before the component boundary
then at least it was logged once so you've got some breadcrumbs you can use
later.


"Kevin Jackson" <kj******@powerwayinc.com> wrote in message
news:eo*************@TK2MSFTNGP09.phx.gbl...

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?

Nov 16 '05 #2
Dave,

After reading your reply and thinking about it, I totally agree. I'm
looking at the Logging block right now. This is a large distributed app
written from scratch. Our last large distributed app was a mess and we
never knew what was going on. I do not want to repeat that on this project.

Thanks for your help on this subject.

Kevin
"Dave" <no****************@wi.rr.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
I don't know of anything in the base exception object itself that you can
use to uniquely identify an exception object but if all your exceptions are custom objects you can add a field that uniquely identifies it (e.g. Guid or a bool) to keep track of the logged exceptions.

Even if you can do that I don't recommend it. One of the benefits of the
exception model is that it allows catch blocks to catch-wrap-throw an
exception, each time adding more context information. This provides a much
richer and more meaningful error message to be presented to the user. I'd
prefer to have it logged at the initial site of the exception (to make sure that at least one record of it is kept), and then once again at the
component boundary (e.g. before it gets thrown across a web service). If the exception gets caught and handled or swallowed before the component boundary then at least it was logged once so you've got some breadcrumbs you can use later.


"Kevin Jackson" <kj******@powerwayinc.com> wrote in message
news:eo*************@TK2MSFTNGP09.phx.gbl...

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?


Nov 16 '05 #3
Hi Kevin,

If you have any further question, please feel free to post in this group.
We will help you.

Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 16 '05 #4
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?

Nov 16 '05 #5
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?

Nov 16 '05 #6
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" <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?


Nov 16 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.