evaluating exception handling

Are your custom exceptions necessary?

Are you deriving from ApplicationException? Deriving from Exception is fine.

Are your exceptions grouped in an exception namespace?

Do your exceptions use localized description strings?

Are you including extra or sensitive information unwisely or unnecessarily?

Are you using exceptions to handle normal code flow? You shouldn’t.

Are you using a tester-doer pattern to help people avoid common exceptions? File.Exists and File.Open for example… Strictly not a great example, but see this msdn guide to exception handling.

Do you return null from methods that would normally return a resource handle of some sort – or do you throw?

Does normal running throw an exception? It shouldn’t.

Are you checking method arguments and throwing ArgumentExceptions? You should.

Is all your cleanup code in finally blocks?

Do your custom exceptions present at least the three common constructors?

Are you catching Exception? Don’t – or at most only once per thread.

Are you using throw ex? Don’t. Just throw and avoid clearing the stack trace.

Are you logging Exception.ToString() in preference to Exception.Message?

What do you do if your finally cleanup fails?

Are your custom exceptions [Serializable]?

 

MSDN Design Guidelines for Exceptions