logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Grabowski <rongrabow...@yahoo.com>
Subject RE: Best practices to avoid logging same information multiple times
Date Thu, 06 Jan 2005 15:09:41 GMT
--- Bill.Martin@Marlborough-Stirling.com wrote:

> My personal view on this is that you should only catch an exception
> where
> you can do something about it.  If you are catching an exception in
> your
> data layer simply to log it and then re-throw it, then you are just
> slowing
> down your application.  Try ... catch is a pretty expensive
> operation.  It
> is valid perhaps if you are then throwing a different exception up to
> your
> business layer, including your original exception as an inner
> exception.

I agreee. We are currently catching data exceptions and re-throwing
them to the business layer wrapped as the appropriate business related
exception. I don't intend for exceptions to be a daily occurance (i.e.
my application doesn't rely on them for application flow). My main goal
to record them and alert someone into improving the code so they don't
occur. By recording them close to where they occur, I feel like I can
give a more detailed log message instead of just dumping ex.ToString().

> If you can't do anything about the exception in the data layer, then
> don't
> catch it.  You will still get the same exception complete with stack
> trace
> at the point you do catch it.  Also if there are only certain

That statement applies only if the exceptions are caught and dealt with
higher up. That was what I was trying to get at in my original post. I
have concern for the case of a junior programmer using my classes to
perform an operation and having them wrap their call inside of a
generic try/catch(Exception) and simply ignoring the exception. The
exceptions continue to occur yet no one is alerted of them. I'm not
always going to have the resources to check every line of code that use
my libraries. While my group may run unit tests on our code, I can't
guarantee that programmers higher up in the chain will. 

I've gotten into one of those loops where I've been thinking about how
best to write defensive code and I've become a little paranoid :-/

Your comments were helpful.

- Ron

View raw message