[Twisted-Python] A few simple questions
Russell E. Owen
rowen at uw.edu
Wed Jul 18 11:31:36 MDT 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