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. Holger P.S.: thanks for changing the subject line, should have done that earlier.
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