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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4