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