xpat error in xmlrp client. How to inspect data.

News123 news1234 at free.fr
Tue Mar 30 23:01:40 CEST 2010


Hi Gabriel,

Gabriel Genellina wrote:
> En Thu, 25 Mar 2010 05:31:05 -0300, News123 <news1234 at free.fr> escribió:
> 
>> I'm havign a small xmlrpc client, which works normally fine.
>> (xmlrpc via https)
>>
>> Sometimes however I receive an Exception about an expat error.
>>
>>
>> The output, that I receive is:
>>   File "C:\mycode\myrpcclient.py", line 63, in upload_chunk
>>     rslt = myrpcclient.call()
>>   File "C:\Python26\lib\xmlrpclib.py", line 1199, in __call__
>>     return self.__send(self.__name, args)
>>   File "C:\Python26\lib\xmlrpclib.py", line 1489, in __request
>>     verbose=self.__verbose
>>   File "C:\Python26\lib\xmlrpclib.py", line 1253, in request
>>     return self._parse_response(h.getfile(), sock)
>>   File "C:\Python26\lib\xmlrpclib.py", line 1387, in _parse_response
>>     p.feed(response)
>>   File "C:\Python26\lib\xmlrpclib.py", line 601, in feed
>>     self._parser.Parse(data, 0)
>> ExpatError: syntax error: line 1, column 0
>>
> 
> a) Use the standard cgitb module (despite its name, it is useful outside
> CGI scripts)
> 
> b) Use the tb module available from http://pypi.python.org/pypi/tb
> 
I'm currently using the default module traceback and code, which looks
roughly like:

try:
  xmlrpccall()
except Exception as e:
  ex_type,ex_value,e_b = sys.exc_info()
  tbstring = traceback.format_exc()
  logging.error('%s:%s:%s' % (ex_type,ex_value,tbstring)


do cgitb or tb really provide much more info?


> Both provide a more verbose traceback, including local variables at each
> execution frame.
> 
> c) Replace ("monkey-patch") the feed() method with a more debug-friendly
> version:
> 
> def feed(self, data):
>   try:
>     self._parser.Parse(data, 0)
>   except xmlrpclib.expat.ExpatError, e:
>     e.args += (data,)
>     raise
> 
> xmlrpclib.ExpatParser.feed = feed

Well, the monkey patch seems to be THE solution for my problem. Thanks a
lot.
Now I'll just have to wait till the problem shows up again.
Probably I'll just display the backtrace in the except section.

> 
> (Or perhaps set e.data = data)
> 
> d) In your exception handler, walk the traceback object until you reach
> the feed() call, and inspect the corresponding tb_frame.f_locals
> dictionary.

How can I walk a traceback? For the current problem the the monkeypatch
should be good enough, but for other cases it might be good to know.



bye

N



More information about the Python-list mailing list