Exceptional inheritance patterns (was Re: [Python-Dev] Python in Unicode context) (original) (raw)

Aahz aahz at pythoncraft.com
Thu Aug 5 18:04:33 CEST 2004

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

More information about the Python-Dev mailing list