the point of routes_onerror is EXACTLY to "intercept" the error and somewhat process it to display a nicer page to the end-user. I'd guess at this point that your controller handling the error has some bugs in it: would you care to trim it to the bare minimum to see if the error is in handling the "original" error ?
On Sunday, January 4, 2015 12:56:54 AM UTC+1, Louis Amon wrote: > > I've tested the native error handler (working fine) versus my custom error > handler (generating HTTP 400 error + web2py stuck) : > > The main difference between the two is that the native error handler > doesn't generate an additional request while routes_onerror seems to > generate an additional request that points to my error handler. > > This second request goes through *copystream_progress* just fine, then > calls *copystream* (at line 125 in globals.py). > > In *copystream*, it gets stuck at line 465 in fileutils.py : > > data = src.read(size) > > This call to 'read' eventually times out. > > I've tried catching the error like this : > > try: > data = src.read(size) > except Exception as e: > print type(e), e > > All it ever prints (after 10 seconds) is : > > <class 'socket.timeout'> timed out > > > How can I further investigate this matter ? > > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
