xpat error in xmlrp client. How to inspect data.

[Gabriel Genellina]

En Tue, 30 Mar 2010 18:01:40 -0300, News123 <news1234 at free.fr> escribió:
> 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?

Well, for each frame along the stack, cgitb shows the value of all  
function arguments, the value of each name referenced, and a few more  
lines of code around the current one. It's rather verbose, but doesn't  
include all local variables.

The tb module shows -also for each frame along the stack- the value of all  
its local names (but doesn't include any global one).

Just try both of them and see which one you like most.

>> 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.

Each traceback object is linked to the next one via its tb_next attribute.  
But inspect.trace() builds a list of traceback records that may be easier  
to handle; see the inspect module documentation. You can identify the  
desired frame with its filename and function name, and then access its  
local variables with f_locals.
I did something like that to gather context information for errors  
happening in a third party library that were hard to diagnose otherwise.

-- 
Gabriel Genellina