Raymond Hettinger wrote:
> FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extra
> significance for the exception hierarchy. The core issue is that
> exceptions are NOT inherently tree-structured. Each may ultimately
> carry its own set of meaningful attributes and those tend to not neatly
> roll-up into a parent/subclass relationships without Liskov violations.
I think this is a key point, because a Python except clause makes it easy to
create an on-the-fly exception grouping, but it is more awkward to get rid of
inheritance that is incorrect (you have to catch and reraise the ones you
don't want handled before the real handler).
I think Raymond gives a good suggestion - new groupings should only be
introduced for exceptions where we have reasonable evidence that they are
already frequently caught together.
TerminalException is a good example of this. "except (KeyboardInterrupt,
SystemExit): raise" is something that should be written often - there is a
definite use case for catching them together. Those two are also examples of
inappropriate inheritance causing obvious usability problems.
Cheers,
Nick.
P.S. Are there any other hardware control people around to understand what I
mean when I say that python-dev discussions sometimes remind me of a poorly
tuned PID loop? Particularly the with statement discussion and this one. . .
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
