Error Logging

[Rasika WIJAYARATNE]

Hi guys,

Please check this out:

http://rkwcoding.blogspot.com/2007/0...r-logging.html

[Jon Skeet [C# MVP]]

On Jul 3, 6:42 am, Rasika WIJAYARATNE <rasi...@gmail. comwrote:

Please check this out:

http://rkwcoding.blogspot.com/2007/0...r-logging.html

I'm not saying it's not an interesting piece (even though I believe
logging should be available at the server as well - it's often a lot
easier to get at, for a start) but I don't think it's worth announcing
every .NET-related blog entry. There are a lot of blogs out there with
some very interesting information - but this isn't the place to
announce them.

All IMO, of course.

Jon

[R. K. Wijayaratne]

Hi Jon,

Thanks for your valuable feedback. Apologies RE the posting of the
blog link.

Where I was coming from was that IMO a server component should be
light-weight and generic and with as little 'baggage' as possible to
maximize universal re-use.

I guess if the server component in question were only used in-house,
and the logging requirements for all the clients were very similar or
the same, logging on the server does make sense.

Rasika.

[Jon Skeet [C# MVP]]

On Jul 3, 9:02 am, "R. K. Wijayaratne" <rasi...@gmail. comwrote:

Thanks for your valuable feedback. Apologies RE the posting of the
blog link.

Where I was coming from was that IMO a server component should be
light-weight and generic and with as little 'baggage' as possible to
maximize universal re-use.

I guess if the server component in question were only used in-house,
and the logging requirements for all the clients were very similar or
the same, logging on the server does make sense.

Being able to log on the server *always* makes sense, in my view:

1) Measuring the performance of components is a lot easier with
logging
2) You can find out whether a problem is encountered by many clients
or just one (people won't always report issues)
3) You can get often hold of the logs much more easily on the server
than from a client
4) You can often change a server to add more logging much more easily
than redeploying clients

It depends what you're doing, but so long as you can make the logging
flexible enough to be easily turned off completely, leaving only
minimal performance impact, I think it's great to have the capability
there.

Jon

[R. K. Wijayaratne]

Thanks for these points...

[R. K. Wijayaratne]

This is the primary scenario that I was thinking of. Lets say that
there is a library (the server code in this case), which has logging
built into it, that is shipped to many different 3rd party clients.

Some of the clients may not want to use logging at all for their
purpose and some may want to use their own custom logging mechanism,
which is not compatible with the shipped library's logging mechanism.

So they are essentially stuck with a logging solution which they don't
want to or can't utilize, which is hanging around inside the library's
compiled code and adding weight to it. This is unless it can be
compiled out of the code before the library is shipped. However in
this case it may take longer to design and build this ability into the
library.

RKW.

[Jon Skeet [C# MVP]]

On Jul 3, 10:29 am, "R. K. Wijayaratne" <rasi...@gmail. comwrote:

This is the primary scenario that I was thinking of. Lets say that
there is a library (the server code in this case), which has logging
built into it, that is shipped to many different 3rd party clients.

Some of the clients may not want to use logging at all for their
purpose and some may want to use their own custom logging mechanism,
which is not compatible with the shipped library's logging mechanism.

So they are essentially stuck with a logging solution which they don't
want to or can't utilize, which is hanging around inside the library's
compiled code and adding weight to it. This is unless it can be
compiled out of the code before the library is shipped. However in
this case it may take longer to design and build this ability into the
library.

On the other hand, if they *do* want logging and you've shipped them a
library that has no logging facilities, they're completely out of
luck.

Many logging libraries are very flexible - if you've already got a
logging solution and you want Log4Net to use it, you can easily write
an adapter, for instance. You configure the logging in a file rather
than hard-coding the configuration, and you're away.

Yes, there's the extra dependency on log4net.dll - no great issues.
Yes, there's still a performance hit even if you don't log - but it's
tiny.

The costs involved in the situation where you don't want any logging
but logging is available are small. The problems created by not having
any logging where you *do* want some are massive.

Jon

[R. K. Wijayaratne]

Great, thank your insight on this.

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Rasika,
Why don't you try pinging Pingomatic.com, or a list of RPC ping servers?
That's the appropriate way to promote your blog posts.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder( BETA): http://www.blogmetafinder.com

"Rasika WIJAYARATNE" wrote:

Hi guys,

Please check this out:

http://rkwcoding.blogspot.com/2007/0...r-logging.html

[R. K. Wijayaratne]

Hi Peter,

Thanks for the links and pointers...