Resource's __call__ has an overzealous TypeError catch

Issue #92 new
Michael Richardson
created an issue

On line 140 of, there's an except TypeError. If this is triggered (say from a TypeError in the code), rather than a 500 error, this results in a 400 error with various debug-style information about the problem. This is pretty bad for a production environment.

The use case this appears to have been designed for (automatically informing people that there are arguments missing) seems to be poorly covered here, as the message given to the user isn't really informative about what is missing and, again, can be triggered by other TypeErrors.

Comments (2)

  1. peterbe

    Attached is a patch that solves this problem. I knocked this together quite quickly but it seems to work. It solves my problem. Now, if I raise a TypeError inside my 'read(request)' method it's treated like any other exception and I get the nice error from piston.

    The testing of the arguments could possibly be much much smarter but it will catch most cases that I can think of.

    If you like the patch I can make a fork and with your help write a test case.

  2. Christopher Peplin

    The new error_handler method in Resource goes a long way in taking care of this problem - I can do whatever I want with the TypeError now. I agree that the backup code that handles TypeError in the library is still probably a bit overzealous, though.

  3. Log in to comment