rdmur...@bitdance.com wrote:
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).
??? I read that before, but I can't understand it.
I think that depends totally on the mail reader you use (although I
don't know any mail reader that scrolls to the bottom).
I use Thunderbird, which opens every message at the top,
so top posting is the best readable for me,
I don't have to scroll (assuming that I know from previous readings the
content of the previous message).
Replying can be preset in any reader I know just as you like, bottom or top.
So I guess there must be another reason, why some (or maybe even
everyone except me) don't prefer top posting.
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.)
well that sound good,
but contains a lot of suggestions with which I'm not familiar.
Could please post some code snippets ?
thanks,
Stef Mientki
--RDM
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
