I agree with Peter Ritchie that Mark Brooks' documentation on exceptions is "exceptionally" good. There are times though, Peter, when catching an exception _is_ the right thing to do (see Mark's 2nd part of #1) and therefore it should not be re-thrown. For example, if I caught a System.IO.FileNotFoundException and then I prompted the user to show me where the file was located, this would be a case where catching an exception without re-throwing is the correct thing to do. You must therefore re-word your suggestion to be "always re-throw exceptions that you catch and don't properly handle" -- but because that statement would violate the primary rules for catching exceptions, I am forced to respectfully disagree with the clarification.
Cheers! --Paul -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ritchie Sent: Friday, September 16, 2005 11:34 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Best way to handle errors in .net Excellent exception practices. I would only clarify that Exception should never be caught without a rethrow. http://www.peterRitchie.com/ Mark Brooks wrote: First as regards exceptions themselves: 1. Do NOT catch exceptions you don't know how to handle - this means correct for the problem or do some unwind work. If you _KNOW_ what to do when an Exception happens, catch. If not, DON'T. 2. Do NOT catch exceptions to merely translate the to another type of exception (even if you do set the InnerException property). If you don't have something to add, don't catch. This is wrong: catch (Exception ex) { // do something interesting (see 1) throw new MyCoolException("nothing of value here", ex); } 3. Do NOT catch an exception then throw it again, rather do a "rethrow". This is wrong: catch (Exception ex) { // do something interesting (see 1) throw ex; // StackTrace now loses everything below this level } Rather do this: catch (Exception ex) { // do something interesting (see 1) throw; // notice there's no ex! The original StackTrace is left intact. } 4. Do NOT derive all of your exceptions from ApplicationException (or some other base level exception of your creation), as you are not adding value by doing so. If you want to standardize your exception creation, write builder methods to throw specific exceptions in regular "forms". 5. If you do have contextual information you can add to an exceptionm, DO SO. Use the Exception.Data collection, that's what it is there for! You can add the values of interesting parameters to you methods. This is especially useful in the context of a database layer or other low-level library. You can squirrel-away the SQL and all the parameters. Only do this if you think that these details will be useful for post-mortem diagnosis. If the information you log is transitory it will NOT help tracking down errors from logs. This is (mostly) good: catch (Exception ex) { ex.Data.Add("SQL", command.Text); ex.Data.Add("key", myKey); // or enumerate command Parameters collection throw; // (see #3) } 6. If you add things to the Exception.Data collection, make sure that you don't conflict with what is already there as this is a HashTable. I use the catching-class's name to scope the values. This is much better than #5: catch (Exception ex) { ex.Data.Add(typeof(MyClass).ToString() + ".MyMethod.SQL", command.Text); throw; // (see #3) } 7. If you are catching exceptions to do some undo-work (like rolling back transactions, closing handles, etc.) Strongly consider creating a _very small_ wrapper for that resource and implementing IDisposable on it. Then you can have a "using" clause to hide the try { } finally { } block. =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
