On 07/11/2013 05:43 AM, Thomas Hervé wrote:
On Thu, Jul 11, 2013 at 1:49 AM, Monty Taylor <[email protected]
<mailto:[email protected]>> 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
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
