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 <a href="http://krondo.com/?page_id=1327">http://krondo.com/?page_id=1327</a>. In particular, until I saw this graphic on callback/errback chaining (<a href="http://krondo.com/blog/wp-content/uploads/2009/10/deferred-2.png">http://krondo.com/blog/wp-content/uploads/2009/10/deferred-2.png</a>), I never properly understood what twisted was doing (linked from this <a href="http://krondo.com/?p=1825">http://krondo.com/?p=1825</a>).<div>
<br></div><div>Naveen<br><div><div><br><div class="gmail_quote">On Wed, Jul 18, 2012 at 1:31 PM, Russell E. Owen <span dir="ltr"><<a href="mailto:rowen@uw.edu" target="_blank">rowen@uw.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In article <<a href="mailto:DB49C8B0-451D-46E4-9B3B-58519CDAA75A@twistedmatrix.com">DB49C8B0-451D-46E4-9B3B-58519CDAA75A@twistedmatrix.com</a>>,<br>
<div><div class="h5"> Glyph <<a href="mailto:glyph@twistedmatrix.com">glyph@twistedmatrix.com</a>> wrote:<br>
<br>
> On Jul 17, 2012, at 9:25 AM, Russell E. Owen <<a href="mailto:rowen@uw.edu">rowen@uw.edu</a>> wrote:<br>
><br>
> >> Can you elaborate on the case?<br>
> ><br>
> > I've found that Twisted sometimes swallows errors unless I am extremely<br>
> > careful. I would like to be able to check a protocol to make sure it is<br>
> > operational (connected and happy) as a means of assuring that I've not<br>
> > missed an error.<br>
><br>
> This isn't really elaborating.<br>
><br>
> What error does Twisted swallow? In what manner do you have to be "careful"?<br>
> What characterizes a protocol's "happiness" beyond its momentary<br>
> connected-ness? How would you "miss" an error?<br>
><br>
> Twisted is event-driven, so pretty much all the state changes you're<br>
> interested in are delivered as events (method calls on your object). If you<br>
> are "missing" them because Twisted isn't calling them, that sounds like a<br>
> really serious bug we should investigate. If you're missing them for some<br>
> other reason then you should just fix your code so it doesn't miss them any<br>
> more :).<br>
<br>
</div></div>Regarding swallowing errors:<br>
<br>
I'm not claiming Twisted has bugs in this area (though I found and<br>
reported one obscure case that may be a bug: errors in tk command<br>
::tk::Mac::quit are silently ignored).<br>
<br>
However, I found it rather easy to make coding errors that cause Twisted<br>
to not report errors. I have heard the same complaint from colleagues.<br>
<br>
At this point I think my code is robust, though I will be more confident<br>
once I finish my unit tests.<br>
<br>
If there is a "best practices for error handling" document I'd love to<br>
read it. I found an overview of deferreds that was helpful. It pointed<br>
out that addCallbacks is not the same as addCallback followed by<br>
addErrback and I'm not sure I'm handling the difference correctly. Right<br>
now I use addCallbacks(callback, errback). This does not call the<br>
errback if the callback fails. I do this intentionally because I want<br>
the errback to focus on problems with the connection, not my reaction to<br>
it, and the default error handler seems to report errors in the<br>
callback, which is fine.<br>
<br>
Regarding state:<br>
<br>
I'm used to event-driven frameworks that both offer callbacks and the<br>
ability to query state. I find it helpful for reporting errors as soon<br>
as possible (e.g. before writing check if the socket is connected; raise<br>
an exception if not). For a TCP/IP socket, I view a socket as having<br>
these states:<br>
- connecting<br>
- connected<br>
- disconnecting (with associated reason)<br>
- disconnected (with associated reason)<br>
TCP/IP Servers have a similar set of states, with connected -> listening<br>
<br>
However, it's certainly true that being able to query state is not<br>
essential; callbacks suffice.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Russell<br>
<br>
<br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</div></div></blockquote></div><br></div></div></div>