[openstack-dev] [Review] Use of exception for non-exceptional cases

Mark McLoughlin markmc at redhat.com
Thu Jul 11 09:20:23 UTC 2013

On Wed, 2013-07-10 at 19:49 -0400, Monty Taylor wrote:
> I'd like top-post and hijack this thread for another exception related
> thing:
> a) Anyone writing code such as:
> try:
>   blah()
> except SomeException:
>   raise SomeOtherExceptionLeavingOutStackContextFromSomeException
> should be mocked ruthlessly.

Ok, mock me ruthlessly then.

Part of designing any API is specifying what predictable exceptions it
will raise. For any predictable error condition, you don't want callers
to have to catch random exceptions from the underlying libraries you
might be calling into.

Say if I was designing an image downloading API, I'd do something like


Assume there's a tonne more stuff that the API would do. You don't want
callers to have to catch socket.error exceptions and whatever other
exceptions might be thrown.

That works out as:

  Traceback (most recent call last):
    File "t.py", line 20, in <module>
      download_image('localhost', 3366, 'foobar')
    File "t.py", line 18, in download_image
      raise ImageDownloadFailure(host, port, path, e.strerror)
  __main__.ImageDownloadFailure: Failed to download foobar from localhost:3366: Connection refused

Which is a pretty clear exception.

But I think what you're saying is missing is the stack trace from the
underlying exception.

As I understood it, Python doesn't have a way of chaining exceptions
like this but e.g. Java does. A little bit more poking right now shows
up this:


i.e. we can't do the right thing until Python 3, where we'd do:

 def download_image(host, port, path):
         s = socket.create_connection((host, port))
     except socket.error as e:
         raise ImageDownloadFailure(host, port, path, e.strerror) from e

I haven't read the PEP in detail yet, though.


More information about the OpenStack-dev mailing list