472,976 Members | 1,234 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,976 software developers and data experts.

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
6 9915
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: JV | last post by:
I just started getting into this, so I hope this isn't a stupid question, but I noticed that the logging block has a feature for logging an additional chunk of contextual data using IDictionary...
0
by: Thomas Wrobel | last post by:
Hi, I got a bit of a tricky problem. I implemented an exception logger, which wrote every exception, that occured in my production system into a database table. I used the example...
3
by: marmaxx | last post by:
I am currently making the transition from Visual Studio .NET 2003 to Visual Studio 2005, and I am looking for suggestions regarding how to implement an exception logging scheme. In my previous...
17
by: Cramer | last post by:
I plan to implement an exception logging feature in an ASP.NET Web application that writes encountered exceptions to disk. The exception data will be stored as XML. I am planning on having each...
0
by: lllomh | last post by:
Define the method first this.state = { buttonBackgroundColor: 'green', isBlinking: false, // A new status is added to identify whether the button is blinking or not } autoStart=()=>{
2
by: DJRhino | last post by:
Was curious if anyone else was having this same issue or not.... I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM) The start time is equivalent to 19:00 (7PM) in Central...
0
by: Aliciasmith | last post by:
In an age dominated by smartphones, having a mobile app for your business is no longer an option; it's a necessity. Whether you're a startup or an established enterprise, finding the right mobile app...
2
by: giovanniandrean | last post by:
The energy model is structured as follows and uses excel sheets to give input data: 1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
1
by: Teri B | last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course. 0ne-to-many. One course many roles. Then I created a report based on the Course form and...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM) Please note that the UK and Europe revert to winter time on...
0
NeoPa
by: NeoPa | last post by:
Introduction For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
0
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.