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.
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 exceptions you can handle in the data layer, then catch only those specific ones and let others propagate. For example, you might want to catch a DBConcurrencyException and re-try the update, but allow other exceptions to propagate up the call stack to where you can do something useful with it. Note: If you do catch an exception and then re-throw it, be sure to use "throw;" rather than "throw ex;" as the latter will reset the stack trace and you will lose information on the source of the exception. HTH, Bill -----Original Message----- From: Ron Grabowski [mailto:[EMAIL PROTECTED] Sent: 06 January 2005 00:00 To: [email protected] Subject: Best practices to avoid logging same information multiple times I'm currently logging exceptions as soon as they occur. If an exception occurs in my data layer, I log it in the catch block of the try it occured. Should that exception also be caught at the very top layer that initiated the exception (i.e. the btnSubmit_Click event that started the form processing)? After seeing all the logging that comes out of frameworks like the Struts Framework for Java and data access libraries like iBatis (in the Java version at least, iBatis.NET doesn't log nearly as much) I find myself wanting to log as much as I can whenever I can. Being able to trace through and find exactly what went wrong has saved me countless hours of guess work. On one hand I welcome more logs but on the other hand I don't want to get carried away with having to decipher why there are two (or more) log entries for all my exceptions. I'm paranoid that if I wait to catch an exception at the top most level I risk the chance of missing it or poluting the stack trace with a lot of unnecessary information. During development I'm finding that I often have a logger for each layer of my application. How is the rest of the list handling things? - Ron UK businesses use 2 million tonnes of paper each year. THINK before you PRINT this email. ______________________________________________________________ CONFIDENTIALITY NOTICE This communication and the information it contains is intended for the person or organisation to whom it is addressed. Its contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you are not the intended recipient, please contact us immediately. The contents of any attachments in this e-mail may contain software viruses, which could damage your own computer system. While Marlborough Stirling has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage, which you sustain as a result of software viruses. You should carry out your own virus checking procedure before opening any attachment. Marlborough Stirling plc, Registered in England and Wales Registered No. 3008820, Jessop House, Jessop Avenue, Cheltenham, Gloucestershire, GL50 3SH Tel: 01242 547000 Fax: 01242 547100 http://www.marlborough-stirling.com
