[Twisted-Python] Unhandled Error in python 3 test suite

[Glyph Lefkowitz]

> On Mar 30, 2015, at 3:52 AM, Adi Roiban <adi at roiban.ro> wrote:
> 
> On 23 March 2015 at 15:29, Tristan Seligmann <mithrandi at mithrandi.net> wrote:
>> On 23 March 2015 at 16:25, HawkOwl <hawkowl at atleastfornow.net> wrote:
>>> It's not really a bug -- it's just that the stderr isn't being captured like real Trial does. Twisted will reraise errors so they show up in logs, but will actually handle them (I think, anyway). The traceback formatting just says it's an unhandled error. That is, it was handled by Twisted, but it was unhandled by user code, and generated an errback or such.
>> 
>> Note that "Unhandled error in Deferred" is the default log message for
>> log.err, and a lot (most?) of the code that logs a failure calls
>> log.err without passing a different message.
> 
> I have no idea what you are talking about :(
> 
> I run deferred related tests using nose and standard pyunit 2.7.
> Each time I see an  "Unhandled error in Deferred"  message in the log
> it means that my test is poorly written and
> does not make an explicit call to check the deferred value.. for
> example using something similar to self.successResultOf()
> 
> If you say that it is ok to ignore those errors, fine by me.

If you run a test under trial that logs a traceback (whether the result of an unhandled error in a Deferred or any other `log.err´ call), the test will fail.

If you run a test under trial that logs a traceback and you call self.flushLoggedErrors() to clear that logged error, then it won't fail.

However, twisted cannot control what your other test runners do, so maybe nose (and definitely stdlib unittest) don't think logged errors are sufficient to fail a test.  Right now lots of tests on the py3 builder with the primitive test runner are spewing tracebacks which are _supposed_ to be logged, and which are properly being caught and "flushed".  When we switch to trial these will show up only in test.log and not on stderr.

> I think that soon we should have trial on py3 and we will no longer
> need to worry about this primitive test runner.


YES.  Thanks to HawkOwl for all her recent work which is going towards making this possible soon!!!

-glyph