can error messages be improved or can they be overridden ?

[rdmurray at bitdance.com]

Stef Mientki <stef.mientki at 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.mientki at 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