Handling exceptions¶
All exceptions are located in the fedora_messaging.exceptions
module.
When publishing¶
When calling fedora_messaging.api.publish()
, the following
exceptions can be raised:
ValidationError
: raised if the message fails validation with its JSON schema. This only depends on the message you are trying to send, the AMQP server is not involved.PublishReturned
: raised if the broker rejects the message.PublishForbidden
: raised if the broker rejects the message because of permissions issues.ConnectionException
: raised if a connection error occurred before the publish confirmation arrived.
The ValidationError
exception means you should fix either the schema (and
maybe make a new version) or the message. No need to catch it, this should
crash your app during development and testing.
Your app may handle the other two exceptions in whichever way is relevant. It should involve logging, and sending again or discarding may be valid options.
You already noticed the ValidationError
being raised when you tried sending
an invalid message in the previous chapter.
When consuming¶
Invalid messages according to the JSON schema are automatically rejected by the client.
The callback function can raise the following exceptions:
Nack
: raise this to return the message to the queueDrop
: raise this to drop the messageHaltConsumer
: raise this to shutdown the consumer and return the message to the queue.
Any other exception will bubble up in the consumer, shut it down, and return pending messages to the queue. Your app will have to handle the exception.
Modify the callback function to raise those exceptions and see what happens.
When returning Nack
systematically, the consumer will just loop on that one
message, as it is put back in the queue and delivered again forever.
Notice how raising HaltConsumer
or another exception stops the consumer,
but does not consume the message: it will be re-delivered on the next startup.