xpat error in xmlrp client. How to inspect data.
gagsl-py2 at yahoo.com.ar
Wed Mar 31 08:22:54 CEST 2010
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
>>> 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
>>> 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:
> 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
> 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.
More information about the Python-list