Logging and exceptions, is it so hard?

  • Thread starter Thread starter Julia
  • Start date Start date
J

Julia

Hi,
So my server is complete,I have all the code and libraries which I need
but now I want to add exception management and logging capabilities

I would like you to suggest a good book about logging and exceptions
handling for multiple threads server

Some question I have in mind are

1.Where is the best place in the component hierarchy to put logging?
(inside the lowest component or the highest one?)

2.Where is the best place in the component hierarchy to put logging of an
exception?
(since I always pass the inner exception,my rule of thumb is to log it
in the highest component in the hierarchy
without crossing thread boundaries)
3.When multiple thread writing to the same log file,performance can be
degraded,how to avoid this?
4.assuming the server write to a log file,I would like the admin program to
display it as it changes
what is a good way(I don't want to throw events to the user interface
when loging )
I know of course i can use mutex,events and MMF like visual studio and
dbmon do

and many more...

Thanks in adavnce.
 
1.Where is the best place in the component hierarchy to put logging?
(inside the lowest component or the highest one?)
Click to expand...

Where you think exceptions are most likely to occur!
An "exception" is just that - an exception to the normal circumstances. If
the circumstances are all normal and all is as you predicted, there should
never be an exception, not if you're program's written correctly! An
exception will most likely occur where there is most scope for user input,
therefore for users to input things wrong or do things in the wrong order.
But you might want to put one slightly higher than that just to be sure.
Or better still, you might want to put specific ones where you think they
will be likely to occur, and a generic 'catch all' one really high up that at
least alerts you that there's something you need to look further into, but
doesn't bring the program down.

2.Where is the best place in the component hierarchy to put logging of an
exception?
(since I always pass the inner exception,my rule of thumb is to log it
in the highest component in the hierarchy
without crossing thread boundaries)
Click to expand...

See below.
3.When multiple thread writing to the same log file,performance can be
degraded,how to avoid this?
Click to expand...

Have a synchronized queue, and then you can allow multiple threads to add
items to the queue. But then only have one thread removing them from the
queue, that writes the details to the log. You could isolate this
functionality into a component, which would answer your previous question.
I know of course i can use mutex,events and MMF like visual studio and
dbmon do
Click to expand...

Thread synchronization in .NET is mightily simple...easier even than C++
I am ... using NSpring library for logging
Click to expand...


Why? How come so many people think they need to use a 3rd party library for
this, that and the other?
You've already said you need to know how to synchronize logging, so this
warez solution obviously doesn't do that for you. The only other thing you
need to do is write to the event log... how hard can it be?
 
Why? How come so many people think they need to use a 3rd party library
for
this, that and the other?
Click to expand...

Two things. For one, most people don't have the time to write and debug
everything they need. That way lies insanity. And the other is that the
EventLog isn't the only option, NSpring offers quite a few different
mechanisms, from email to files to the event log to whatever. Combination
and layering of those services based on log level is usually the reason to
use a complicated logging environment.
 
"Where you think exceptions are most likely to occur!
An "exception" is just that - an exception to the normal circumstances. If
the circumstances are all normal and all is as you predicted, there should
never be an exception, not if you're program's written correctly! An
exception will most likely....."

If component A uses Component B, and B raise an exception I can log it
either in component B
or in Component A.so my question was what to take in consideration when
placing the log.
for example put it in B give me more information regarding the exception but
force component B to be familier
with the login technology
On the other hand if B used by several components and contain log code it
will be much harder to
find which component currently use B.

"Have a synchronized queue, and then you can allow multiple threads to add
items to the queue. But then only have one thread removing them from the
queue, that writes the details to the log. You could isolate this
functionality into a component, which would answer your previous question."

Ok it is a good idea(basically what you say that synchronized queue won't
hart performance like a synchronized access to a file?)

"Why? How come so many people think they need to use a 3rd party library for
this, that and the other?"

Time constraints.

Thanks.
 
Many people use the exception management application block from Microsoft,
but for your use, I would suggest the Logging Application Block instead. It
is much more in tune with the EIF (Enterprise Instrumentation Framework),
which means that you can use one of many different drivers to decide where
you want the log record to go. The same framework is good for sending
performance monitoring statistics to PerfMon, as well as sending events to
the event log, sql tables, or text files (with a fail-over from one to the
next, in whatever order you prefer).

If component A uses Component B, and B raise an exception I can log it
either in component B
or in Component A.so my question was what to take in consideration when
placing the log.
for example put it in B give me more information regarding the exception but
force component B to be familier
with the login technology
On the other hand if B used by several components and contain log code it
will be much harder to
find which component currently use B.
Click to expand...


In my team, the standard is to HANDLE the event as close to the error as
possible, but if handling the event requires propogation, to propogate an
application error and LOG the event at the highest possible level. The
distinction is that the code that handles the event is not necessarily the
same code that logs it. By definition, all ApplicationException events have
been handled. To prevent multiple logging, if we decide to log an event,
and then propogate it anyway (say across class library boundaries) then we
define a custom event to embed it in. Custom events have been both handled
and logged.

Hope this helps,
--- Nick
 
Julia said:
Hi,
So my server is complete,I have all the code and libraries which I need
but now I want to add exception management and logging capabilities

I would like you to suggest a good book about logging and exceptions
handling for multiple threads server

Some question I have in mind are

1.Where is the best place in the component hierarchy to put logging?
(inside the lowest component or the highest one?)
Click to expand...

Log the exceptions in all the catch blocks that do not rethrow. If you
follow this simple rule, all exceptions will be logged and they will be
logged only once.
2.Where is the best place in the component hierarchy to put logging of an
exception?
(since I always pass the inner exception,my rule of thumb is to log it
in the highest component in the hierarchy
without crossing thread boundaries)
3.When multiple thread writing to the same log file,performance can be
degraded,how to avoid this?
Click to expand...

Normally, exceptions should be "exceptional". So, the overhead of logging
them can be neglected. If this is really an issue, you can use a queue, but
you have to be careful about not filling memory if the queing rate gets too
high. I prefer to keep the exception logging simple, to be sure that it will
work (and that the logging itself does not raise exceptions).

If several threads are going to write their exceptions to the same log file,
you can handle this by synchronizing the log function on a single global
object. Something like

private static readonly object _logLock = new object();

public static void Log(Exception ex)
{
lock (_logLock) { /* your file I/O to log */ }
}
 
Back
Top