«

Hi,

If an exception gets raised while I am parsing an input file I would
like to know where (in which line) the error occured. I do not want to
create my own exception class for that purpose and I also do not want to
deal with all possible kinds of exceptions that might occur.

I came up with the following code:

inp = file(file_name)
for n, line in enumerate(inp):
try:
# parse line ...
except Exception, e:
inp.close() # Is this necessary for 'r' files?
args = list(e.args)
args.insert(0, 'line: %d'%(n+1))
e.args = tuple(args)
raise

Which looks like this in the traceback:

ValueError: ('line: 3', 'invalid literal for float(): not_a_number')

Is this the 'correct' way to do that?
Is there any specific order to the arguments in e.args? Should my 'user
argument' be at the beginning or at the end of e.args?

Thanks! Andreas

Andreas Beyer wrote:
> I came up with the following code:
> inp = file(file_name)
> for n, line in enumerate(inp):
> try:
> # parse line ...
> except Exception, e:
> inp.close() # Is this necessary for 'r' files?
> args = list(e.args)
> args.insert(0, 'line: %d'%(n+1))
> e.args = tuple(args)
> raise
inp = open(file_name) # GvR prefers this style, not file
try:
for n, line in enumerate(inp):
try:
# parse line ...
except Exception, e:
e.args = e.args + ('line: %d' % (n + 1),) # tuple add
raise
finally:
inp.close() # it is certainly more portable, and more readable


> Is there any specific order to the arguments in e.args?
> Should my 'user argument' be at the beginning or at the end of e.args?

If you are going to play with it, it is more likely that indices
are used (so making e.args[0] refer to the same thing may help).
The __str__ method of the Exception is responsible for formatting.
If you "wrap" an exception that has its own __str__ method, it
may well expect the args tuple to hold a precise number of
elements (and therefore fail to convert to a string).

--Scott David Daniels