[openstack-dev] [Review] Use of exception for non-exceptional cases
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
> a) Anyone writing code such as:
> 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.
More information about the OpenStack-dev