All too often I find myself (and so naturally I assume a good many others do as well) getting so wrapped up in the latest set of technologies or innovations or focus on really complex problem domains that we miss and/or forget the relatively small and foundational stuff that is really best practice.
Scott Hanselman has posted a list of Exception Management Rules of Thumb that is a great refresher on this topic. Included in this list are possibly some things that are new to you. Here are two that are really good and show great _common-software-engineering-sense
If your functions are named well, using verbs (actions) and nouns (stuff to take action on) then **throw an exception if your method can’t do what it says it can. **
- _For example, SaveBook(). If it can’t save the book - it can’t do what it promised - then throw an exception. That might be for a number of reasons. _
_If something horrible happens (something exceptional) then you need to decide if you can keep going. _
- Don’t catch exceptions you can’t do anything about. It’s likely if you could do something about it, it wouldn’t be exceptional, and you might consider calling TryParse, or File.Exists, or whatever it takes to prevent that exception.
Tags: hanselman, scott hanselman, exceptions, exception handling, exception management, rules of thumb