On 10/31/06, Marcin Kasperski <Marcin.Kasperski@softax.com.pl> wrote:
One more observation after looking at twisted code:
twisted/protocols/basic.py funtion LineReceiver.dataReceived contains sth like that:
why = self.lineReceived(line) if why or self.transport and self.transport.disconnecting: return why
As this is WITHIN the loop, we see why returning deferred (or anything true) from lineReceived breaks processing.
I did not search further but it seems somebody is using convention that if lineReceived (and maybe dataReceived) returns something, then this is an error. Why not exception??? And, is it possible to patch it somehow so lineReceived function could be unit-tested?
While Twisted's handling of the result of lineReceived is perhaps confusing, I find your reasons for wanting it changed dubious: your unit tests should be testing that lineReceived has the appropriate *effects*, not that arbitrary points in the code are reached by testing its return value (which would have no effect in the actual running of your program). -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/