--- [EMAIL PROTECTED] 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
