Why not just show the out-of-range index?

John Machin sjmachin at lexicon.net
Mon Dec 4 16:27:06 EST 2006


OKB (not okblacke) wrote:
[snip]
>     	I think the same could be said of virtually all exceptions.  What I
> think would be ideal is that whenever an exception is raised, the
> traceback tells you:
>
>     	1) What the exception is
>     	2) The names of the variables involved in the offending expression
> (or their character position in the line)
>     	3) The values of those variables
>
>     	This would be especially useful in cases where you have some long
> expression and you get a "cannot concatenate str and list" or whatever.
> The irritating thing about this as it is is that you cannot tell which
> variables in the expression are causing the problem.
>
>     	I realize that in some cases the offending expression may not be a single variable,
> but I am curious whether it would be possible for
> something like this:
>
> "1" + "2" + "3" + "4" + 5 + "6"

A few points:

1. You have difficulty determining the "offending expression" in that
example?

2. If I read your requirement properly, you want an error message that
includes the following information from the source:

example 1: "1" + "2" + "3" + "4" + 5 + "6"
left operand name: "1" + "2" + "3" + "4"
left operand value: "1234"
right operand name: 5
right operand value: 5

example 2 (simple variables): str1 = "a"; list1 = ["b"]; foo = str1 +
list1
left operand name: str1
left operand value: "a"
right operand name: list1
right operand value: ["b"]

example 3 (simple variables): str1 = "a"; str2 = "x"; list1 = ["b"];
foo = str1 + str2 + list1
left operand name: str1 + str2
left operand value: "ax"
right operand name: list1
right operand value: ["b"]

IMHO there would be no point in handling only "simple" cases like
example 2 -- firstly, you don't need it; there's only one possible
answer for "left operand name". Secondly, AFAICT, the same mechanism
would handle examples of arbitrary complexity.

My guesses: (a) Implementing this error reporting information in a new
compiler and interpreter would add considerably to the effort required,
and to the complexity and thus to the risk of error. (b) Retrofitting
it to an existing compiler and interpreter would be a nightmare.
Possible: yes. Cost/benefit ratio: very high.

3. The OP asked only for values; you are asking for names and values.
If you have a magic flak jacket, please let me know; I'd like to borrow
it occasionally :-)

Cheers,
John




More information about the Python-list mailing list