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

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. 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 raised exceptions. Thanks. -- David