HTTPRequest.resolve_url has error in raising errors

[Patrick Gerken]

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

[Patrick Gerken (do3cc)]

Uploaded: testHTTPRequest.py.patch

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

[Patrick Gerken (do3cc)]

> 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 ;-)

[Andreas Jung (ajung)]

Status: Pending => Resolved

Patch applied to 2.8-2.10 branch, trunk

[Andreas Jung (ajung)]

Status: Resolved => Pending

Reverted change for 2.9,2.10, trunk

[Patrick Gerken (do3cc)]

Uploaded: httprequest.patch

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

[Tres Seaver (tseaver)]

The patch doesn't apply cleanly, but the bug exists (and raises a string exception, to boot).

[Jens Vagelpohl (dataflake-deactivatedaccount-deactivatedaccount)]

Fixed on...

Zope 2.12 branch: http://svn.zope.org/?rev=114736&view=rev

Zope trunk: http://svn.zope.org/?rev=114737&view=rev