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

[Aahz]

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