Opened 5 years ago

Last modified 4 months ago

#5310 defect new

WrapperException makes debugging Agent hard

Reported by: glyph Owned by: exarkun
Priority: normal Milestone:
Component: web Keywords:
Cc: jknight, twm@… Branch: branches/agent-exceptions-5310
(github, coverage, patch, buildbot, log)
Author: exarkun


If request generation fails with Agent it is difficult to debug because _WrapperException swallows tracebacks automatically and provides no facility to extract them manually.

For example, this (buggy) program:

from twisted.internet import reactor
from twisted.web.client import Agent
agent = Agent(reactor)
class Whatever(object):
    I should probably implement some interfaces or something.
def done(it):
    return it
(agent.request("POST", "", bodyProducer=Whatever())

produces the following inscrutable output:

Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
Failure: twisted.web._newclient.RequestGenerationFailed: [
    <twisted.python.failure.Failure <type 'exceptions.AttributeError'>>]

RequestGenerationFailed apparently has no public alias; neither does _WrapperException, which means that there's no way to catch this exception and do better error reporting without resorting to importing private names.

Also, _WrapperException's documentation is wrong: while its subclasses get things right, it says that reasons is a list of exceptions, when it is in fact a list of Failures.

Change History (7)

comment:1 Changed 5 years ago by DefaultCC Plugin

  • Cc jknight added

comment:2 Changed 5 years ago by exarkun

For some reason this was filed again as #5345

comment:3 Changed 3 years ago by therve

And was already filed as #4659, but I kept this one.

comment:4 Changed 2 years ago by exarkun

  • Author set to exarkun
  • Branch set to branches/agent-exceptions-5310

(In [41819]) Branching to 'agent-exceptions-5310'

comment:5 Changed 2 years ago by exarkun

  • Keywords review added

comment:6 Changed 2 years ago by glyph

  • Keywords review removed
  • Owner set to exarkun

Thanks for addressing this, exarkun!

I think it's OK to land as you see fit. Thanks for the import cleanups.

The one thought that occurs to me, looking at this, is that most users will encounter this exception initially via its repr, and will have no particular context for discerning its public alias. This is, of course, a more general issue, but if you would like to add a __repr__ and a test for it that adjusts the name so that users will find the right API documentation to look at, that would be a good start.

Perhaps this also needs some narrative documentation that explains how you might hit this sort of error though.

Also, do you think we should file a separate ticket for somehow making printTraceback print the wrapped exception's traceback too? Part of the inscrutability of the error here is that, by default, when it's reported, it's really just not clear at all why, and the type of the wrapped exception(s) isn't enough information to discern that.

comment:7 Changed 4 months ago by twm

  • Cc twm@… added
Note: See TracTickets for help on using tickets.