En Tue, 30 Mar 2010 18:01:40 -0300, News123 <news1...@free.fr> escribió:
Gabriel Genellina wrote:
En Thu, 25 Mar 2010 05:31:05 -0300, News123 <news1...@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
--
http://mail.python.org/mailman/listinfo/python-list
