3 Commits

Author SHA1 Message Date
Christian Berendt
5be1b6a6a9 Enabled hacking checks H305 and H307
* H305  imports not grouped correctly
* H307  like imports should be grouped together

Change-Id: I08dafc4fa150d2213b2bb002da7c9ee0ee517fac
2014-07-17 12:41:21 +02:00
Doug Hellmann
7b13bc1888 Update ExpectedException handling
Catch expected exceptions in a way that supports subclasses also being
seen as "expected."

Log a little more detail about unexpected exceptions in the ExecutorBase
so it is easier to add them to the list of expected exceptions.

Change-Id: I1bdd628eba717308f0afe1a889efd8711bad6296
Closes-bug: #1276163
2014-02-05 09:32:42 -08:00
Mark McLoughlin
f6df32d943 Add API for expected endpoint exceptions
Review I4e7b19dc730342091fd70a717065741d56da4555 gives a lot of the
background here, but the idea is that some exceptions raised by an RPC
endpoint method do not indicate any sort of failure and should not be
logged by the server as an error.

The classic example of this is conductor's instance_get() method raising
InstanceNotFound. This is perfectly normal and should not be considered
an error.

The new API is a decorator which you can use with RPC endpoints methods
to indicate which exceptions are expected:

    @messaging.expected_exceptions(InstanceNotFound)
    def instance_get(self, context, instance_id):
        ...

but we also need to expose the ExpectedException type itself so that
direct "local" users of the endpoint class know what type will be used
to wrap expected exceptions. For example, Nova has an ExceptionHelper
class which unwraps the original exception from an ExpectedException and
re-raises it.

I've changed from client_exceptions() and ClientException to make it
more clear it's intent. I felt that the "client" naming gave the
impression it was intended for use on the client side.

Change-Id: Ieec4600bd6b70cf31ac7925a98a517b84acada4d
2013-08-07 12:52:54 +01:00