On Tue, Oct 13, 2009 at 8:02 PM, Steve Steiner (listsin) <span dir="ltr">&lt;<a href="mailto:listsin@integrateddevcorp.com">listsin@integrateddevcorp.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;ve been hunting down a problem that I&#39;ve finally found the cause of<br>
and I&#39;d like to know what&#39;s the Twisted way to catch this &quot;error<br>
within the code handling the error&quot;  type of error.<br></blockquote><div><br>The right way to catch this is to write tests for your code and run them before deploying it to production :).  Trial will helpfully fail tests which cause exceptions to be logged, so you don&#39;t need to write any special extra test to make sure that nothing is blowing up; just test your error-handling case, and if it blows up you will see it.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Basically, in one branch of the errBack, there was a typo.  A simple<br>
typo that caused an unhandled NameError exception, but only once in  a<br>
few thousand runs.<br></blockquote><div><br>If it&#39;s a NameError, you also could have used Pyflakes to catch it :).<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

The exception got caught and &quot;displayed&quot; by Twisted, but it wasn&#39;t<br>
going anyplace anyone was looking (buried under zillions of lines of<br>
logging) and the app continues on as if nothing went wrong.<br></blockquote><div><br>The real lesson here is that you should be paying attention to logged tracebacks.<br><br>There are many ways to do this.  Many operations teams running Twisted servers will trawl the logs with regular expressions.  Not my preferred way of doing it, but I&#39;m not really an ops person :).<br>
<br>If you want to handle logged exceptions specially, for example to put them in a separate file, or to e-mail them to somebody, consider writing a log observer that checks for the isError key and does something special there.  You can find out more about writing log observers here: &lt;<a href="http://twistedmatrix.com/projects/core/documentation/howto/logging.html">http://twistedmatrix.com/projects/core/documentation/howto/logging.html</a>&gt;.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">What is the best way to handle programming errors like this in<br>
deferreds so they don&#39;t slip by, unnoticed?<br></blockquote></div><br>I&#39;m answering a question you didn&#39;t ask, about logged errors, because I think it&#39;s the one you meant to ask.  The answer to the question you are actually asking here, i.e. &quot;how do I handle errors in an errback&quot;, is quite simple: add another errback.  This is sort of like asking how to handle exceptions in an &#39;except:&#39; block in Python.  For example, if you want to catch errors from this code:<br>
<br>try:<br>  foo()<br>except:<br>  oops()<br><br>you could modify it to look like this:<br><br>try:<br>  foo()<br>except:<br>  try:<br>    oops()<br>  except:<br>    handleOopsOops()<br><br>which is what adding another errback is like.  But, as I said: I don&#39;t think this is what you want, since it will only let you handle un-handled errors in Deferreds (not unhandled errors in, for example, protocols) and you will have to attach your error-handling callbacks everywhere (not to mention trying to guess a sane return value for the error-handler-error-handler.<br>
<br><br>