[Twisted-Python] A few simple questions
naveenm at enthought.com
Wed Jul 18 13:43:59 EDT 2012
If you haven't seen it already, Dave Peticolas has a great introduction to
twisted (it's a bit long, but well worth it) at
http://krondo.com/?page_id=1327. In particular, until I saw this graphic on
callback/errback chaining (
http://krondo.com/blog/wp-content/uploads/2009/10/deferred-2.png), I never
properly understood what twisted was doing (linked from this
On Wed, Jul 18, 2012 at 1:31 PM, Russell E. Owen <rowen at uw.edu> wrote:
> 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
> > 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
> > 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
> > other reason then you should just fix your code so it doesn't miss them
> > 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
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python