[Twisted-Python] PB locally logging errors from deferreds in remote_* methods
db3l at fitlinxx.com
Thu May 13 17:19:13 EDT 2004
I was wondering if anyone knew the rationale for why Twisted's PB logs
any errors (using log.err) that may be returned from a deferred that
has been returned in response to a remote_* call on a pb.Referenceable
object? It seems like a fairly standard situation, where the error is
just something to be reflected back to the client.
For example, I've got a series of components in a system I'm working
on that were designed from the beginning to return deferreds from
their APIs, even when they operated locally (e.g., there's plenty of
use of defer.succeed() and defer.fail()). This was specifically to
isolate calling code from the anticipated future case when some of
those components might be relocated remotely, and the application code
would be interacting with remote wrapper objects using PB to
communicate with the now relocated components.
So I'm working on the future case now, but found that whenever one of
my component entry points decided to return an error (which was always
done by sending a Failure up the deferred chain), while that error is
being reflected back to the wrapper object, my server side is also
logging the error on the console.
>From what I can see that's because pb.py uses _sendFailure as the
Errback for a deferred returned from a remote_* method, where
_sendFailure logs the error (with a prefix line as a log message, but
the failure object as an error message). But to me this is like
logging every time a client application receives a proper error
notification to an API request.
If the remote_* methods were raise()ing the exceptions, I could
subclass pb.Error and then _sendError gets used instead, but there's
no equivalent on the deferred chain path.
For my own use, locally modifying pb.py to use _sendError in the
Errback rather than _sendFailure cleans it up, but I was wondering if
anyone else had noticed this and/or felt that _sendError was a more
appropriate Errback in the first place? It doesn't feel right to
consider it a bug, since it feels more like a design decision, but I'd
think it would be nice to have at least as much control over the local
logging of errors in the deferred chain as you have with locally
More information about the Twisted-Python