launchpad development
Catching exceptions
Never catch AssertionError or NameError or TypeError.
Only catch ValueError when you are trying to convert a value to a type using the builting "type conversion" functions such as int() and float().
try:
foo = int(foo_str)
except ValueError:
# Handle the non-int case.You might want to catch TypeError when converting type, when the value may be a string or may be None. Resist this temptation! You should explicitly check for a None value before doing the conversion.
if foo_str is None:
# Handle None value.
try:
foo = int(foo_str)
except ValueError:
# Handle the non-int case.
Raising exceptions
Raise AssertionError when code that calls your code has not met its part of the contract. Use AssertionError if your code has been passed code of the wrong type. Don't use TypeError for this.
The reason is that we're writing an application, not a framework, not a general purpose library. We live and die by the contracts between the pieces of our application. When the contracts are not adhered to, we need to know that unambiguously.
Application code should never raise TypeError or NameError.
There are very limited circumstances in which it's OK to raise ValueError. Usually, it's more appropriate to use a more specific exception. However, if you have a function which converts data from one form to another in a way similar to int() or float(), raising ValueError may be appropriate.
In general, don't make your specific exceptions derive from ValueError. ValueError is an error saying something about where in the structure of the code the error is assumed to be: in some argument to a function, or something like that. That assumption is often unhelpful or misleading.
We should be more interested in what condition occured than whether the error might have been passed as an argument to a function at some point or other. Reflect this in your choice of exceptions.
Breaking the rules
There are some occassions when infrastructure code needs to break these rules. These are special cases. They should be few, and specially commented.
