ping wrote: > On Tue, 11 Jul 2000, Fred L. Drake, Jr. wrote: > > At one point, we were discussing having specializations of > > SyntaxError, and I posted a patch that defined IndentationError and > > TabError. >=20 > I guess the question is, will we ever want to catch or distinguish > just IndentationError or TabError exceptions in particular from > within a Python program? TabError maybe (retabify and try again -- but if you'll implement that, you might as well untabify before compiling), but I cannot see any reason to handle IndentationError. Also sucks from a documentation perspective... I'm -1 (on this part of the patch). > I can't personally think of any situations where i would need more > detail than SyntaxError (whatever the error is, i'll just want to > say "syntax error" and show the message)... unless... should the > expected token type be passed *all* the way back to the user level > so that e.g. an IDE can provide a UI hint as to how to correct the > syntax error? and in that case, the IDE won't be interested in actually showing the exception type to anyone... It's probably better to add extra info to the exception object, such as an "error tag" which is guaranteed to stay the same, no matter what the message is changed into (I'd love to have this in Python- Works, for example). guess it's time to grep for SyntaxError exceptions... </F>
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