Ka-Ping Yee wrote:
I wrote:
The strongest reason is that a long file with a typo in a string literal somewhere in hundreds of lines of code generates only
ValueError: invalid \x escape
with no indication to where the error is -- not even which file!
Thomas Wouters wrote:
This has nothing to do with the error being a ValueError, but with some (compile-time) errors not being promoted to 'full' errors. See
I think they are entirely related. All ValueErrors should be run-time errors; a ValueError should never occur during compilation. The key issue is communicating clearly with the user, and that's just not what ValueError *means*.
M.-A. Lemburg wrote:
Right and I think this touches the core of the problem. SyntaxErrors produce a proper traceback while ValueErrors (and others) just print a single line which doesn't even have the filename or line number.
This follows sensibly from the fact that SyntaxErrors are always compile-time errors (and therefore have no traceback or frame at the level where the error occurred). ValueErrors are usually run-time errors, so .filename and .lineno attributes would be redundant; this information is already available in the associated frame object.
Those attributes are added to the error object by set_error_location() in compile.c. Since the error objects are Python instances, the function will set those attribute on any error which the compiler raises and IMHO, this would be a good thing.
Perhaps lifting the restriction in PyErr_PrintEx() and making the parse_syntax_error() API a little more robust might do the trick. Then the various direct PyErr_SetString() calls in compile.c should be converted to use com_error() instead (if possible).
That sounds like a significant amount of work, and i'm not sure it's the right answer.
Changing all compile time errors to SyntaxError requires much the same amount of work... you'd have to either modify the code to use com_error() or check for errors and then redirect them to com_error() (e.g. for codec errors).
If we just clarify the boundary by making sure make sure that all, and only, compile-time errors are SyntaxErrors, everything would work properly and the meaning of the various exception classes would be clearer. The only exceptions that don't currently conform, as far as i know, have to do with invalid literals.
Well, there are also system and memory errors and the codecs are free to raise any other kind of error as well. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/