[Twisted-Python] A few simple questions

[Naveen Michaud-Agrawal]

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 <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
> "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 at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20120718/8ee7aba5/attachment.html>