[ZCM] [ZC] 1944/ 6 Comment "HTTPRequest.resolve_url has error in raising errors"

Collector: Zope Bugs, Features, and Patches ... zope-coders-admin at zope.org
Sun Jul 2 16:07:12 EDT 2006


Issue #1944 Update (Comment) "HTTPRequest.resolve_url has error in raising errors"
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/1944

==============================================================
= Comment - Entry #6 by do3cc on Jul 2, 2006 4:07 pm


Uploaded:  "httprequest.patch"
 - http://www.zope.org/Collectors/Zope/1944/httprequest.patch/view
It seems that in the meantime the resolving of URLs got pickier. So this time the test creates a better objects to traverse and it works again with the current trunk. This time the patch can be applied to the root of your zope checkout, via patch -p0 < httprequest.patch
________________________________________
= Resubmit - Entry #5 by ajung on Jun 12, 2006 2:29 am

 Status: Resolved => Pending

Reverted change for 2.9,2.10, trunk
________________________________________
= Resolve - Entry #4 by ajung on Jun 12, 2006 1:32 am

 Status: Pending => Resolved

Patch applied to 2.8-2.10 branch, trunk
________________________________________
= Comment - Entry #3 by do3cc on Nov 12, 2005 9:23 pm

>   ZPublisher.HTTPRequest.resolve_url(). This raises an error, and the
>   comment in the beginning of the method promises, it would raise the same
>   error it would raise if somebody would have called this URL. But it
>   raises a type error.

I was wondering why I catch a TypeError, and sys.exc_info() didn't show that to me. I tried to reproduce it in simpler scripts but did not succeed. More strangely, after that I was also not able any more to reproduce the TypeError. I have absolutely no idea, WHAT type of error gets thrown with the current implementation, I was not able to catch it, and suspect a really really weird python bug. But it seems beyond my capabilities to reproduce the thing. Or I just need some sleep on a saturday at 3 o'clock in the morning. If anybody reading this is as curious as me and also wants to try to find out which exception gets thrown, and if this really does not match the information shown by sys.exc_info(), please let me know your results. I want to die without knowing it ;-)
________________________________________
= Comment - Entry #2 by do3cc on Nov 12, 2005 8:22 pm


Uploaded:  "testHTTPRequest.py.patch"
 - http://www.zope.org/Collectors/Zope/1944/testHTTPRequest.py.patch/view
Now that I have the Issue number, here is the updated test file.
To apply the patch, please go to the directory of the file testHTTPRequest.py and enter
patch testHTTPRequest.py < /some/path/testHTTPRequest.py.patch
________________________________________
= Request - Entry #1 by do3cc on Nov 12, 2005 8:14 pm


Uploaded:  "HTTPRequest.py.patch"
 - http://www.zope.org/Collectors/Zope/1944/HTTPRequest.py.patch/view
I try to resolve a nonexistent URL with ZPublisher.HTTPRequest.resolve_url(). This raises an error, and the comment in the beginning of the method promises, it would raise the same error it would raise if somebody would have called this URL. But it raises a type error.
This is what happens:
In the line where it wants to raise the error, some arguments got set wrong:
raise rsp.errmsg, sys.exc_info()[1]

rsp.errmsg is a string, and raise will raise now rsp.errmsg.__class__(sys.exc_info()[1]) which terribly fails, and raises an TypeError.
A Patch is attached.
To apply it, go to the directory where HTTPRequest.py resides and enter
patch HTTPRequest.py < /some/path/HTTPRequest.py.patch
==============================================================



More information about the Zope-Collector-Monitor mailing list