Prepending to traceback

[Stefan Behnel]

Hi!

I'm writing a parser using pyparsing and I would like to augment the
ParserException tracebacks with information about the actual error line *in
the parsed text*. Pyparsing provides me with everything I need (parsed line
and column), but is there a way to push that information on the traceback?


To make it a bit clearer, tracebacks currently look like this:

Traceback (most recent call last):
...
File "/usr/lib/python2.4/site-packages/pyparsing.py", line 456, in parse
loc,tokens = self.parseImpl( instring, loc, doActions )
File "/usr/lib/python2.4/site-packages/pyparsing.py", line 727, in parseImpl
raise exc
ParseException: Expected "SOMEOTHERTERM" (146), (5,9)


I want them to look like this:

Traceback (most recent call last):
...
File "/usr/lib/python2.4/site-packages/pyparsing.py", line 456, in parse
loc,tokens = self.parseImpl( instring, loc, doActions )
File "/usr/lib/python2.4/site-packages/pyparsing.py", line 727, in parseImpl
raise exc
PyParsing, line 5, in SomeStatement
PARSER TEST FOR TESTING MISSING TERM
ParseException: Expected "SOMEOTHERTERM" (146), (5,9)


where "PARSER TEST FOR TESTING MISSING TERM" is a line parsed by pyparsing
that leads to raising a ParseException. I wouldn't mind too much not having
the original traceback, though I'd prefer it. I remember having read somewhere
that there is a way to embed an exceptions in another one, that might help.

How can I alter or create such Tracebacks?

Thanks,
Stefan

 

[Thomas Guettler]

Am Wed, 02 Feb 2005 13:55:24 +0100 schrieb Stefan Behnel:

Hi!

I'm writing a parser using pyparsing and I would like to augment the
ParserException tracebacks with information about the actual error line *in
the parsed text*. Pyparsing provides me with everything I need (parsed line
and column), but is there a way to push that information on the traceback?

Hi,

have a look at the source of ParseException. I guess there
is attribute which holds the string. If the attribute is "msg",
you could do it like this:

try:
....
except ParseException, e:
e.msg="Textbefore %s" % e.msg
raise e

(code is not tested)

Thomas

 

[Larry Bates]

Replace system exception hook with your on function that gets
called when exception is raised (not fully tested):

#
# Define a function that is called when system exception happens
#
def excepthook(self, type, value, tb):
#
# This function allows the user to redefine what happens if the program
# aborts due to an uncaught exception.
import traceback
#
# Prepend your lines to tblines list here
#
tblines=['PyParsing, line 5, in SomeStatement\n',
'PARSER TEST FOR TESTING MISSING TERM\n']

#
# Get traceback lines and append the current session log
#
tblines.extend(traceback.format_exception(type, value, tb))
map(sys.stdout.writelines, tblines) # Always write exceptions to screen
sys.exit(2)

#
# At top of your main program:
# Set the sys.excepthook so I can clean up properly if main program aborts
#
sys.excepthook=excepthook

Larry Bates

 

[Ian Bicking]

I want them to look like this:

Traceback (most recent call last):
...
File "/usr/lib/python2.4/site-packages/pyparsing.py", line 456, in parse
loc,tokens = self.parseImpl( instring, loc, doActions )
File "/usr/lib/python2.4/site-packages/pyparsing.py", line 727, in
parseImpl
raise exc
PyParsing, line 5, in SomeStatement
PARSER TEST FOR TESTING MISSING TERM
ParseException: Expected "SOMEOTHERTERM" (146), (5,9)

This query's a little old now, but I found this through the Weekly URL.

Anyway, Zope's ExceptionFormatter has one answer to this; you put a
local variable like:

__traceback_info__ = ('PyParsing, line %i, in %s\n %s'
% (line, statement, message))

And then that will show up in the traceback, much like you want. The
formatter looks through all the frames for this local variable and
prints it out when found. It's used in Zope for showing line numbers
and other information when its interpreting scripts like Zope Page
Templates or Python Scripts -- so that instead of just seeing the
traceback from the interpreter, you also see information about what the
interpreter is doing. This sounds similar to what you want.

It's pretty simple to use and it doesn't depend on the rest of Zope:
http://cvs.zope.org/Products/ErrorR...rev=HEAD&content-type=text/vnd.viewcvs-markup