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 http://krondo.com/?p=1825).
Naveen On Wed, Jul 18, 2012 at 1:31 PM, Russell E. Owen <ro...@uw.edu> wrote: > In article <db49c8b0-451d-46e4-9b3b-58519cdaa...@twistedmatrix.com>, > Glyph <gl...@twistedmatrix.com> wrote: > > > On Jul 17, 2012, at 9:25 AM, Russell E. Owen <ro...@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 > > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python >
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
