Error reporter and documentation view assume handlers are always functions.

Issue #212 new
Graham Dumpleton
created an issue

The HandlerMethod instance which gets used by error reporter for errors and documentation views assumes that the handler will always be a function.

If it isn't, then HandlerMethod.iter_args() will fail on the call inspect.getargspec(self.method).



File "/opt/python/domains/" in call 166. result = self.error_handler(e, request, meth, em_format) File "/opt/python/domains/" in error_handler 259. sig = hm.signature File "/opt/python/domains/" in signature 44. for argn, argdef in self.iter_args(): File "/opt/python/domains/" in iter_args 27. args, , , defaults = inspect.getargspec(self.method) File "/opt/python/2.7.2/lib/python2.7/" in getargspec 813. raise TypeError('{!r} is not a Python function'.format(func))

Exception Type: TypeError at /api/1.0/repositories/brodie/cpython/issues/1/comments Exception Value: <newrelic.hooks.component_piston.MethodWrapper object at 0x35dd950> is not a Python function }}}

The situation where it will not be a function is where a decorator/wrapper is used which doesn't used nested functions to implement the decorator. In other words, where the decorator is actually implemented using a class object.

In this situation it isn't actually possible to derive a signature. One can't even assume that if the class object for the decorator object has a call() method that that should be used because a get() method descriptor could be used instead to resolve call to something else.

Anyway, a try/except should be used around the getargspec() call and if it fails the code should fallback to displaying a messaging indicating that the argument specification could not be determined.

A small example which illustrates the problem is attached as with corresponding file.

Comments (0)

  1. Log in to comment