qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: exceptions in the new apis
Date Mon, 25 Jan 2010 14:29:44 GMT
On 01/21/2010 01:29 PM, Gordon Sim wrote:
> The c++ and python messaging apis need to clearly define the exceptions
> that can be thrown as well as when and where they can be thrown from.
> As a start I'd like to compile a list of the important error conditions
> that can occur. I'm hoping other will chip in with changes and additions
> and without too much effort we can get a reasonably complete list agreed
> and then decide how to design the exception hierarchy used to
> communicate them.
> The final stage will be determining which exceptions each method in the
> api may throw. There may be some exceptions very specific to particular
> methods that are more obvious when we reach that stage.
> * tcp socket fails (or whatever the rdma equivalent is, assuming that is
> a detectable condition)

That should probably be a generic "connection failure" to cover failures of 
existing and future transports. Should we distinguish failure to establish 
connection from failure of an established connection? Note that if the client is 
doing failover the distinction is somewhat blurred.

> * missed heartbeats
> * authentication errors
> * authorisation errors
> * queue not found
> * exchange not found
> * other address validation errors (e.g. exchange is of different type to
> that specified)
> * session terminated by management
> * connection terminated by management
> * broker side queue limit breached
> * exclusive subscriber violation
> * feature not supported exception from broker (e,g, unsupported exchange
> type)
> * protocol violation errors (by which I mean any sort of framing error
> or problem that is a result of a bug in the library or broker rather
> than being an invalid command by the application)
> * internal error in broker, i.e. some as yet unidentified bug,
> misconfiguration or environmental problem

* internal error in client: same thing for client-side misconfiguration or bugs.

* Exceeded client-side limitation: a client-side queue is over-full. E.g. user 
has not respected flow control limits on the client side.

* Transaction related errors - not sure what the set is, probably just copy from 
spec exceptions.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message