Stef Mientki <stef.mien...@gmail.com> wrote: > thanks Ron, > > but I was looking for a more general solution, > in which I don't change the program itself, > and where the error messages (in general) become more informative than > it is by default. [snip] > >> -----Original Message----- > >> From: Stef Mientki [mailto:stef.mien...@gmail.com] [snip] > >> I often get an error message like this > >> > >> self.Brick.Par [ self.EP[2] ]['FileName'] = filename > >> IndexError: list index out of range > >> > >> Now it would be very welcome, > >> if the error message specified which index is out of range, > >> in this case e.g., > >> - specifying the length of self.EP > >> - specifying the value of self.EP[2] > >> - specifying the length of self.Brick.Par etc.. > >> > >> Is there a way to override the error message and provide this > >> information, or is it impossible ? > >> > >> And if it's possible, am I the only one who often stumbles > >> about this problem ? > >> (I expect many people must have bounced in this problem before me ;-)
FYI, top posts are much harder to read and to reply to than if you edit the message to which you are replying and add your new content interleaved or at the bottom (as I have done). No you are not the only one who wishes the error messages were more informative. In one complex application I had, I made my life easier with a hack I copied from Zope. Briefly, at the top level of the program I trap all exceptions, get the traceback object from sys.exc_info, format it with format_tb, and then process it to add info. I applied several enhancements, but the one relevant to you was to grab the locals dictionary from the last frame of the traceback, and use a regex to split the last source line in the formatted traceback up into candidate variable names. Then I printed the name and the repr of the value of any of those names I found in the locals dict. That wouldn't tell you directly which variable it was threw the index error, but having the current values of the variables involved saves a lot of time (no need to go back and stick in prints in many cases). (You know, I really ought to revisit that routine and make it part of my standard development toolbox.) --RDM -- http://mail.python.org/mailman/listinfo/python-list
