Zusammenfassung

Python hat in Version 2.4 38 Ausnahmen (einschließlich Warnungen) im integrierten Namensraum in einer eher flachen Hierarchie. Diese Klassen sind im Laufe der Jahre ohne die Möglichkeit entstanden, aus Erfahrungen zu lernen. Dieser PEP schlägt eine Reorganisation der Hierarchie für Python 3.0 vor, wenn die Abwärtskompatibilität keine so große Rolle spielt.

Zusammen mit dieser Reorganisation wird gefordert, dass alle Objekte, die an eine raise-Anweisung übergeben werden, von einer bestimmten Oberklasse erben müssen. Dies dient dazu, Garantien über die grundlegende Schnittstelle von Ausnahmen zu haben und die natürliche Hierarchie von Ausnahmen weiter zu verbessern.

Schließlich werden leere except-Klauseln semantisch äquivalent zu except Exception geändert. Die meisten Leute verwenden derzeit leere except-Klauseln zu diesem Zweck, und mit der Reorganisation der Ausnahmenhierarchie wird dies zu einer praktikablen Standardeinstellung.

Begründung für den Wunsch nach einer Änderung

Ausnahmen sind ein kritischer Teil von Python. Während Ausnahmen traditionell verwendet werden, um Fehler in einem Programm zu signalisieren, werden sie auch für die Flusskontrolle für Dinge wie Iteratoren verwendet.

Obwohl ihre Bedeutung groß ist, fehlt ihnen die Struktur. Dies liegt daran, dass jedes Objekt als Ausnahme ausgelöst werden kann. Aus diesem Grund hat man keine Garantie, welche Art von Objekt ausgelöst wird, was jede mögliche Hierarchie von ausgelösten Objekten zerstört.

Aber Ausnahmen haben eine Hierarchie, die den Schweregrad der Ausnahme zeigt. Die Hierarchie gruppiert auch verwandte Ausnahmen zusammen, um das Abfangen in except-Klauseln zu vereinfachen. Um es den Leuten zu ermöglichen, sich auf diese Hierarchie zu verlassen, wird eine gemeinsame Oberklasse vorgeschlagen, von der alle ausgelösten Objekte erben müssen. Sie ermöglicht auch Garantien über die Schnittstelle zu ausgelösten Objekten (siehe PEP 344). Eine Diskussion darüber hat bereits auf python-dev stattgefunden [1].

Wie leere except-Klauseln derzeit sind, fangen sie *alle* Ausnahmen ab. Das kann zwar praktisch sein, ist aber für den häufigen Fall etwas übertrieben. Dank einer erforderlichen Oberklasse ist das Abfangen aller Ausnahmen so einfach wie das Abfangen einer bestimmten Ausnahme. Dies ermöglicht es, leere except-Klauseln für einen nützlicheren Zweck zu verwenden. Auch dies wurde auf python-dev diskutiert [2].

Schließlich werden leichte Änderungen an der Ausnahmenhierarchie sie in Bezug auf die Struktur viel vernünftiger machen. Durch geringfügiges Umordnen können Ausnahmen, die typischerweise nicht abgefangen werden sollten, bis zur Spitze des Ausführungsstapels propagieren und den Interpreter wie beabsichtigt beenden.

Philosophie der Auslagerung

Bei der Reorganisation der Hierarchie wurde eine allgemeine Philosophie verfolgt, die sich aus der Diskussion früherer Entwürfe dieses PEP entwickelte [4], [5], [6], [7], [8], [9]. In erster Linie ging es darum, nichts zu zerbrechen, was funktioniert. Das bedeutete, dass die Umbenennung von Ausnahmen außer Frage stand, es sei denn, der Name wurde als stark schlecht eingestuft. Das bedeutete auch, dass keine Ausnahmen entfernt wurden, es sei denn, sie wurden als wirklich fehlplatziert angesehen. Neue Ausnahmen wurden nur in Situationen eingeführt, in denen es nützlich sein könnte, eine Oberklasse einer Kategorie von Ausnahmen abzufangen. Schließlich wurde der Vererbungsbaum bestehender Ausnahmen nur geändert, wenn man der Meinung war, dass sie von vornherein wirklich fehlplatziert waren.

Für alle neuen Ausnahmen musste das richtige Suffix gewählt werden. Für diejenigen, die einen Fehler signalisieren, wird "Error" verwendet. Wenn die Ausnahme eine Warnung ist, dann "Warning". "Exception" wird verwendet, wenn keines der anderen Suffixe geeignet ist und kein spezifisches Suffix besser passt.

Danach ging es darum zu entscheiden, welche Ausnahmen von Exception erben sollten und welche nicht. Dies diente dazu, leere except-Klauseln nützlicher zu machen.

Zuletzt musste die gesamte bestehende Hierarchie von der neuen Ausnahme erben, die als erforderliche Oberklasse für alle Ausnahmen dienen soll.

Neue Hierarchie

+-- BaseException (new; broader inheritance for subclasses)
    +-- Exception
        +-- GeneratorExit (defined in PEP 342)
        +-- StandardError
            +-- ArithmeticError
                +-- DivideByZeroError
                +-- FloatingPointError
                +-- OverflowError
            +-- AssertionError
            +-- AttributeError
            +-- EnvironmentError
                +-- IOError
                +-- EOFError
                +-- OSError
            +-- ImportError
            +-- LookupError
                +-- IndexError
                +-- KeyError
            +-- MemoryError
            +-- NameError
                +-- UnboundLocalError
            +-- NotImplementedError (stricter inheritance)
            +-- SyntaxError
                +-- IndentationError
                    +-- TabError
            +-- TypeError
            +-- RuntimeError
            +-- UnicodeError
                +-- UnicodeDecodeError
                +-- UnicodeEncodeError
                +-- UnicodeTranslateError
            +-- ValueError
            +-- ReferenceError
        +-- StopIteration
        +-- SystemError
        +-- Warning
            +-- DeprecationWarning
            +-- FutureWarning
            +-- PendingDeprecationWarning
            +-- RuntimeWarning
            +-- SyntaxWarning
            +-- UserWarning
        + -- WindowsError
    +-- KeyboardInterrupt (stricter inheritance)
    +-- SystemExit (stricter inheritance)

Unterschiede im Vergleich zu Python 2.4

Eine gründlichere Erklärung der Begriffe ist bei der Diskussion von Vererbungsänderungen erforderlich. Vererbungsänderungen führen entweder zu einer breiteren oder einer restriktiveren Vererbung. "Breiter" bedeutet, wenn eine Klasse einen Vererbungsbaum wie cls, A hat und dann zu cls, B, A wird. "Strenger" ist das Gegenteil.

Erforderliche Oberklasse für raise

Durch die Anforderung, dass alle Objekte, die an eine raise-Anweisung übergeben werden, von einer bestimmten Oberklasse erben müssen, sind alle Ausnahmen garantiert bestimmte Attribute zu haben. Wenn PEP 344 akzeptiert wird, sind die dort beschriebenen Attribute garantiert auf allen ausgelösten Ausnahmen vorhanden. Dies sollte die Fehlersuche erleichtern, indem die Abfrage von Informationen aus Ausnahmen viel einfacher wird.

Die vorgeschlagene Hierarchie hat BaseException als erforderliche Basisklasse.

Leere except-Klauseln fangen Exceptions

In den meisten bestehenden Python 2.4-Codes sind leere except-Klauseln zu breit in den abgefangenen Ausnahmen. Typischerweise sollen nur Ausnahmen abgefangen werden, die einen Fehler signalisieren. Das bedeutet, dass Ausnahmen, die zum Beenden des Interpreters verwendet werden, im häufigen Fall nicht abgefangen werden sollten.

Da KeyboardInterrupt und SystemExit nun von BaseException statt von Exception erben, wird die Änderung leerer except-Klauseln, um als except Exception zu fungieren, zu einer viel vernünftigeren Standardeinstellung. Diese Änderung wird auch nur sehr wenig Code brechen, da diese Semantik das ist, was die meisten Leute für leere except-Klauseln wollen.

Die vollständige Entfernung leerer except-Klauseln wurde argumentiert. Es wurde argumentiert, dass sie sowohl Only One Way To Do It (OOWTDI) als auch Explicit Is Better Than Implicit (EIBTI) aus The Zen of Python verletzen. Aber Practicality Beats Purity (PBP), ebenfalls im Zen of Python, schlägt beide in diesem Fall. Der BDFL hat erklärt, dass leere except-Klauseln auf diese Weise funktionieren werden [14].

Migrationsplan

Aufgrund der Komplexität und des Aufwands, der für die Hinzufügung aller in diesem PEP geplanten Funktionen erforderlich wäre, ist der Übergangsplan sehr einfach. In Python 2.5 wird BaseException hinzugefügt. In Python 3.0 treten alle verbleibenden Funktionen (erforderliche Oberklasse, Änderung der Vererbung, leere except-Klauseln werden gleichbedeutend mit except Exception) in Kraft. Um all dies in Python 2.5 abwärtskompatibel zu gestalten, wären sehr tiefe Hacks in der Ausnahmen-Maschinerie erforderlich, die fehleranfällig sein und zu einer Verlangsamung der Leistung bei geringem Nutzen führen könnten.

Um den Übergang zu erleichtern, werden die Dokumentationen geändert, um mehrere Programmierrichtlinien widerzuspiegeln

• Wenn man *alle* Ausnahmen abfangen möchte, fange BaseException ab.
• Um alle Ausnahmen abzufangen, die nicht das Beenden des Interpreters darstellen, fange Exception explizit ab.
• Fange KeyboardInterrupt und SystemExit explizit ab; verlasse dich nicht auf die Vererbung von Exception, um erfasst zu werden.
• Fange NotImplementedError immer explizit ab, anstatt sich auf die Vererbung von RuntimeError zu verlassen.

Die Dokumentation für das Modul 'exceptions' [3], das Tutorial [15] und PEP 290 müssen alle aktualisiert werden.

Abgelehnte Ideen

Danksagungen

Vielen Dank an Robert Brewer, Josiah Carlson, Alyssa Coghlan, Timothy Delaney, Jack Diedrich, Fred L. Drake, Jr., Philip J. Eby, Greg Ewing, James Y. Knight, MA Lemburg, Guido van Rossum, Stephen J. Turnbull, Raymond Hettinger und alle anderen, die ich übersehen habe, für die Teilnahme an der Diskussion.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.