On Thu, Aug 05, 2004, Holger Krekel wrote: > Aahz wrote: >> On Thu, Aug 05, 2004, Holger Krekel wrote: >>> Guido van Rossum wrote: >>>> >>>> (It will also break code that creates a class used as an exception >>>> that doesn't derive from Exception, but those should be shot. :-) >>> >>> Then i guess that searching down into a recursive structure and just >>> raising an "i found it" result object up doesn't count as a use case in >>> your book, right? It can avoid boilerplate code like return-if-not-None >>> checks and I have used it for e.g. finding patterns in an AST-Tree. >> >> In cases where I've done this, I've always inherited from Exception or a >> subclass. Is there any reason not to? > > Sure, i can probably wrap the result object into some class which > inherits from Exception. My point is that I like to regard try/except > as a mechanism for "out-of-band" objects. Guidos "should be shot" > seems to indicate he sees try/except only useful/applicable to > exception-handling. Nope, he meant exactly what he said: an exception that doesn't derive from Exception. After all, the iterator protocol relies on similar out-of-band exceptions, and the ``for`` loop has done the same with IndexError for years. Further discussion about Pythonic exception handling should probably get moved to comp.lang.python -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." --reddy at lion.austin.ibm.com
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