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 DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
