Hi Eric,<br><br><div class="gmail_quote">On Sun, Jan 27, 2013 at 11:44 AM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I understand it, yes. If a remote exception is found, raise it. If there is a fatal local exception, raise RPCException. The entirety of impl_zmq's public methods do not simply wrap everything in try/except block, so it is possible that there could be an uncaught exception betsides RemoteError or RPCException that gets raised. My understanding of the amqp-based drivers is that their code behaves similarly in all regards.<br>
</blockquote><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Checking, the only method invoked by impl_zmq.call() that seems likely to raise an exception that isn't currently caught is _deserialize() which wraps jsonutils.dumps(). This could be caught and made to raise RPCException. All the other methods invoked by impl_zmq.call() seem to either raise zmq.ZMQError (which is caught and reraised as RPCException) or directly raise RPCException.<br>

<br>
If you believe there is a bug or misbehavior in the zeromq driver, I'll very happily persue and resolve it.<br></blockquote><div><br>Thanks for making me feel better about this code.  I was misunderstanding what I was reading.  I hadn't noticed the special wrapper methods that begin with '-' and was thinking the proxy.dispatch which invokes the remote method is called directly from ConsumerBase.process().  I now see it is called indirectly through private_ctx.reply() which is protected by try/except.  Great!<br>
<br>I think you could also add some hardening by using dictionary get() method on the "data" variable in ConsumerBase.process(), but that probably isn't a big concern.<br><br>Ray<br></div></div>