The basic tenant, in .net, is if you can't handle the exception don't. Don't catch it, don't log it. If you are going to display an error message, log and display. If you are going to let the client handle it, log it wrap it and throw. Anywhere else is overkill and you risk to log the exception more than once.
Davy "When all you have is a hammer, every problem looks like a nail." I feel much the same way about xml -----Original Message----- From: Mark Hurd <[email protected]> Sender: [email protected] Date: Fri, 11 Mar 2011 10:57:48 To: ozDotNet<[email protected]> Reply-To: ozDotNet <[email protected]> Subject: Re: Rethrowing exceptions IIRC in the Reflector output of the Framework there are a number of similar constructs. Some can be explained (such as the ones in the Microsoft.VisualBasic namespace) where they explicitly WANT to lose the extra history so the exception looks like it is local to the VB routine and not from something deeper in the framework. But there are other versions of this construct, including with just Throw, where I cannot confirm the reason. Of course, the shared source may explain it it due to logging and other code being commented out in the live build. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.) On 11 March 2011 08:57, Noon Silk <[email protected]> wrote: > You did not mean to send this only to me, I'm sure :P > > Anyway, the point is that you can log something and then throw it up > the chain for someone else to deal with. It's appropriate to log > errors, but just because you log doesn't mean you can actually do > anything better than crash (upwards). > > I think it should also be purely "throw"; as I believe "throw ex" > loses some history. > > > On Fri, Mar 11, 2011 at 9:24 AM, Arjang Assadi <[email protected]> > wrote: >> What is the point of catching and throwing the same exception e.g. : >> >> catch (Exception ex) >> { >> throw ex; >> } >> >> ? >> >> Thank you in advance >> >> Regards >> >> Arjang >> > > -- > Noon Silk >
