[Twisted-Python] A few simple questions

Russell E. Owen rowen at uw.edu
Wed Jul 18 13:31:36 EDT 2012

In article <DB49C8B0-451D-46E4-9B3B-58519CDAA75A at twistedmatrix.com>,
 Glyph <glyph at twistedmatrix.com> wrote:

> On Jul 17, 2012, at 9:25 AM, Russell E. Owen <rowen at uw.edu> wrote:
> >> Can you elaborate on the case?
> > 
> > I've found that Twisted sometimes swallows errors unless I am extremely 
> > careful. I would like to be able to check a protocol to make sure it is 
> > operational (connected and happy) as a means of assuring that I've not 
> > missed an error.
> This isn't really elaborating.
> What error does Twisted swallow?  In what manner do you have to be "careful"? 
>  What characterizes a protocol's "happiness" beyond its momentary 
> connected-ness?  How would you "miss" an error?
> Twisted is event-driven, so pretty much all the state changes you're 
> interested in are delivered as events (method calls on your object).  If you 
> are "missing" them because Twisted isn't calling them, that sounds like a 
> really serious bug we should investigate.  If you're missing them for some 
> other reason then you should just fix your code so it doesn't miss them any 
> more :).

Regarding swallowing errors:

I'm not claiming Twisted has bugs in this area (though I found and 
reported one obscure case that may be a bug: errors in  tk command 
::tk::Mac::quit are silently ignored).

However, I found it rather easy to make coding errors that cause Twisted 
to not report errors. I have heard the same complaint from colleagues.

At this point I think my code is robust, though I will be more confident 
once I finish my unit tests.

If there is a "best practices for error handling" document I'd love to 
read it. I found an overview of deferreds that was helpful. It pointed 
out that addCallbacks is not the same as addCallback followed by 
addErrback and I'm not sure I'm handling the difference correctly. Right 
now I use addCallbacks(callback, errback). This does not call the 
errback if the callback fails. I do this intentionally because I want 
the errback to focus on problems with the connection, not my reaction to 
it, and the default error handler seems to report errors in the 
callback, which is fine.

Regarding state:

I'm used to event-driven frameworks that both offer callbacks and the 
ability to query state. I find it helpful for reporting errors as soon 
as possible (e.g. before writing check if the socket is connected; raise 
an exception if not). For a TCP/IP socket, I view a socket as having 
these states:
- connecting
- connected
- disconnecting (with associated reason)
- disconnected (with associated reason)
TCP/IP Servers have a similar set of states, with connected -> listening

However, it's certainly true that being able to query state is not 
essential; callbacks suffice.

-- Russell

More information about the Twisted-Python mailing list