<html><body>On 27 Nov, 06:19 pm, ncesar@lunix.com.ar wrote:<br />&gt;El Sábado, 25 de Noviembre de 2006 02:39, glyph@divmod.com escribió:<br />&gt;&gt; &gt;I was wondering if twistd/the application class could have a "exit on<br />&gt;&gt; &gt;Exception" for this type of operations.<br /><br />&gt;&gt; In general this is a bad idea. &#160;There are basically 3 kinds of code you can<br />&gt;&gt; write with Twisted:<br />&gt;&gt;<br />&gt;&gt; &#160; 1. Infrastructure code, which implements a protocol and provides APIs for<br />&gt;&gt; parsing and dealing with events. &#160;This kind of code should never contain a<br />&gt;&gt; reactor.stop at all.<br /><br />&gt;Actually is type 1, but there are horrible (network) conditions were de<br />&gt;application should stop.<br /><br />No, there aren't. &#160;What happens when I run your application in-process with my webserver? &#160;Should the webserver stop simply because your protocol is not working?<br /><br />&gt;Even it's not type 3, I get your point. And thats why I didn't want to write<br />&gt;ANY reactor.stop() call, instead just raise exceptions- And have a unnified<br />&gt;reactor.stop() inside somewhere in twistd. But it seems I need to think<br />&gt;another solution. Right now as a workaround, reactor.stop() will be inside my<br />&gt;exception's __init__ function ;-)<br /><br />Just don't call reactor.stop at all unless you are writing top-level infrastructure code. &#160;Your application should have some other, more structured way of reporting fatal shut-down errors to its run container (e.g. runContainer.applicationEncounteredFatal(xxx)), not simply raising exceptions and hoping someone is listening. &#160;Unless you give more specifics that indicate that your special case is special-er than any other I've seen before, I'll stand by this. :)<br /><br />&gt;&gt; Don't try to always stop the *process* when your program is<br />&gt;&gt; complete: stop the *program* by keeping a Deferred around which represents<br />&gt;&gt; its complete run. &#160;That way the *driver* for the program is responsible for<br />&gt;&gt; stopping it, and when you want to aggregate multiple runs of it, you can<br />&gt;&gt; easily use a tool like DeferredList, or do something different in the<br />&gt;&gt; callbacks at the end.<br />&gt;<br />&gt;I couldn't understand much of this last parragraph (my English reading could<br />&gt;be part of the problem). I understand algorithms mucho more when are written<br />&gt;in python instead of English, &#160;Do you have a link to some code explaning<br />&gt;this?<br /><br />It's hard for me to think of a program which does this in a simple way. &#160;If I can think of one I will post an example.<br /></body></html>