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

Sean Dague sean at dague.net
Thu Jul 11 10:22:25 UTC 2013

On 07/11/2013 05:43 AM, Thomas Hervé wrote:
> On Thu, Jul 11, 2013 at 1:49 AM, Monty Taylor <mordred at inaugust.com
> <mailto:mordred at inaugust.com>> 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.
> i don't think mocking is a good way to convey your point. Losing
> tracebacks is not great, but having an API raising random exceptions is
> probably worse. Can you develop?

We have defined APIs. We have server projects that call other server 
projects through python-fooclients. We have python-fooclients that 
generate exceptions and stack traces on any non 20X return.

So we have a general exception translation issue. Because unless we want 
nova-api returns to be completely fluid based on what 
keystone/neutron/glance/cinder clients decided their exceptions are this 
week, you have to translate. And the stack trace from a 404 isn't 
something that we really care about from the client, we care that it 
happened, because that affects nova logic, but it's an expected exception.

And where would we even put the stack trace? take it to the user on 
their API call? fill up the logs with stack traces for normal events 
(thus hiding real errors)? (we actually have some blueprints openned now 
to remove these because a *normal* passing tempest run generates 30+ 
stack traces in nova logs, which aren't actually internal errors.)

The bulk of these cases I've seen in Nova are exactly of that nature. We 
actually have a pretty standard pattern of 3 levels of exception 
translations for user API calls.

Underlying client exception (be it DB / python-fooclient) -> Nova 
internal exception -> Webobj exception to create our 40x / 50x returns.


Sean Dague

More information about the OpenStack-dev mailing list