[Python-Dev] SyntaxError for illegal literals

[M.-A. Lemburg]

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/