Fix HTTPError __init__ for cases where fp is None.

The HTTPError class tries to act as a regular response objects for
HTTP protocol errors that include full responses.  If the failure is
more basic, like no valid response, the __init__ choked when it tried
to initialize its superclasses in addinfourl hierarchy that requires a
valid response.

The solution isn't elegant but seems to be effective.  Do not
initialize the base classes if there isn't a file object containing
the response.  In this case, user code expecting to use the addinfourl
methods will fail; but it was going to fail anyway.

It might be cleaner to factor out HTTPError into two classes, only one
of which inherits from addinfourl.  Not sure that the extra complexity
would lead to any improved functionality, though.

Partial fix for SF bug # 563665.

Bug fix candidate for 2.1 and 2.2.
This commit is contained in:
Jeremy Hylton 2002-06-03 16:53:00 +00:00
parent 65230a2de7
commit 40bbae3b03
1 changed files with 6 additions and 2 deletions

View File

@ -157,13 +157,17 @@ class HTTPError(URLError, addinfourl):
__super_init = addinfourl.__init__
def __init__(self, url, code, msg, hdrs, fp):
self.__super_init(fp, hdrs, url)
self.code = code
self.msg = msg
self.hdrs = hdrs
self.fp = fp
# XXX
self.filename = url
# The addinfourl classes depend on fp being a valid file
# object. In some cases, the HTTPError may not have a valid
# file object. If this happens, the simplest workaround is to
# not initialize the base classes.
if fp is not None:
self.__super_init(fp, hdrs, url)
def __str__(self):
return 'HTTP Error %s: %s' % (self.code, self.msg)