Pyrage: Generic Exceptions
Earlier while talking to Ryan I decided I’d try to coin the term “pyrage” referring to some frustrations I was having with some Python packages. The notion of “pyrage” can extend to anything from a constant irritation to a pure “WTF were you thinking!” kind of moment.
Not one to pass up a good opportunity to bitch publicly, I’ll elaborate on some of my favorite sources of “pyrage”, starting with generic exceptions. While at Slide, one of the better practices I picked up from Dave was the use of specifically typed exceptions to specific errors. In effect:
## Pretend this object has "stuff"
class InvalidConnectionError(Exception): pass class ConnectionConfigurationError(Exception): pass def configureConnection(conn): if not isinstance(conn, Connection): raise InvalidConnectionError('configureConnection requires a Connection object') if conn.connected: raise ConnectionConfigurationError('Connection (%s) is already connected' % conn) ## etc </code>
Django, for example, is pretty stacked with generic exceptions, using builtin exceptions like ValueError and AttributeError for a myriad of different kinds of exceptions. urllib2’s HTTPError is good example as well, overloading a large number
of HTTP errors into one exception leaving a developer to catch them all, and check the code, a la:
except urllib2.HTTPError, e:
if e.code == 503:
## Handle 503's special