String-Ausnahmen

Es wird angenommen, dass die Entfernung von String-Ausnahmen unumstritten sein wird, da sie seit mindestens Python 1.5 beabsichtigt ist, als die Standard-Ausnahmetypen in Klassen geändert wurden [1].

Zur Aufzeichnung: String-Ausnahmen sollten entfernt werden, da die Existenz zweier Arten von Ausnahmen die Sprache ohne Entschädigung kompliziert. Instanz-Ausnahmen sind überlegen, weil zum Beispiel

• die Klasse-Instanz-Beziehung den Zusammenhang zwischen Ausnahmetyp und -wert natürlicher ausdrückt,
• sie können naturgemäß mit Hilfe von Superklasse-Unterklasse-Beziehungen organisiert werden, und
• sie können Fehlerberichtsverhalten (zum Beispiel) kapseln.

Implizite Instanziierung

Guidos Essay von 1997 [1] über die Umwandlung der Standard-Ausnahmen in Klassen macht deutlich, warum raise implizit instanziieren kann

„Die raise-Anweisung wurde erweitert, um das Auslösen einer Klassen-Ausnahme ohne explizite Instanziierung zu ermöglichen. Die folgenden Formen, die „Kompatibilitätsformen“ der raise-Anweisung genannt werden […] Die Motivation für die Einführung der Kompatibilitätsformen war, die Rückwärtskompatibilität mit altem Code zu ermöglichen, der eine Standard-Ausnahme auslöste.“

Zum Beispiel war es gewünscht, dass Code vor 1.5, der die String-Ausnahme-Syntax verwendete, wie z.B.

raise TypeError, 'not an int'

sowohl auf Python-Versionen, in denen TypeError ein String war, als auch auf Versionen, in denen es eine Klasse war, funktionieren würde.

Wenn keine solche Überlegung vorliegt – das heißt, wenn der gewünschte Ausnahmetyp in keiner Softwareversion, die der Code unterstützen muss, ein String ist –, gibt es keinen guten Grund, implizit zu instanziieren, und es ist klarer, es nicht zu tun. Zum Beispiel

1. Im Code

   try:
       raise MyError, raised
   except MyError, caught:
       pass
   

   die syntaktische Parallele zwischen der raise- und except-Anweisung legt nahe, dass ausgelöst und gefangen sich auf dasselbe Objekt beziehen. Bei String-Ausnahmen ist dies tatsächlich der Fall, bei Instanz-Ausnahmen jedoch nicht.

2. Wenn die Instanziierung implizit ist, ist nicht offensichtlich, wann sie auftritt, zum Beispiel, ob sie auftritt, wenn die Ausnahme ausgelöst oder wenn sie gefangen wird. Da sie tatsächlich bei der raise geschieht, sollte der Code dies sagen.

   (Beachten Sie, dass auf der Ebene der C-API eine Ausnahme „ausgelöst“ und „gefangen“ werden kann, ohne instanziiert zu werden; dies wird als Optimierung verwendet, z. B. von PyIter_Next. Aber in Python ist keine solche Optimierung verfügbar oder sollte verfügbar sein.)

3. Eine implizit instanziierende raise-Anweisung ohne Argumente, wie z. B.

   raise MyError
   

   tut einfach nicht, was sie sagt: sie löst nicht das genannte Objekt aus.

4. Die Gleichheit von

   raise MyError
   raise MyError()
   

   vermischt Klassen und Instanzen und schafft eine mögliche Verwirrungsquelle für Anfänger. (Außerdem ist nicht klar, ob der Interpreter zwischen einer neuen Klassenart und einer Instanz einer solchen Klasse unterscheiden könnte, so dass die implizite Instanziierung ein Hindernis für jeden zukünftigen Plan sein könnte, Ausnahmen zu neuen Klassenobjekten zu machen.)

Kurz gesagt, die implizite Instanziierung hat keine Vorteile außer der Rückwärtskompatibilität, und daher sollte sie zusammen mit dem, wofür sie zur Gewährleistung der Kompatibilität existiert, nämlich String-Ausnahmen, schrittweise abgebaut werden.

Migrationsplan

from __future__ import raise_with_two_args

raising strings will be impossible in the future

raising classes will be impossible in the future

raising with three arguments will be impossible in the future

Beispiele

class MyError(Exception):
    pass

raise MyError, 'spam'

raise MyError('spam')

MyError = 'spam'
raise MyError, 'eggs'

class MyError(Exception):
    pass

raise MyError('eggs')

raise MyError, 'spam', mytraceback

raise MyError('spam'), mytraceback

from __future__ import raise_with_two_args

raise sys.exc_type, sys.exc_info, sys.exc_traceback

raise

Neue Ausnahme-Arten

Die implizite Instanziierung könnte mit zukünftigen Plänen zur Verwendung von Instanzen von neuen Klassen als Ausnahmen in Konflikt geraten. Um zu entscheiden, ob implizit instanziiert werden soll, muss die raise-Maschinerie feststellen, ob das erste Argument eine Klasse oder eine Instanz ist – aber bei neuen Klassen gibt es keine klare und starke Unterscheidung.

Unter diesem Vorschlag würde das Problem vermieden, da die Ausnahme bereits instanziiert worden wäre. Es gibt jedoch zwei plausible alternative Lösungen

1. Erfordern, dass Ausnahmetypen Unterklassen von Exception sind und implizit instanziieren, wenn und nur wenn

   issubclass(firstarg, Exception)
   

2. Implizit instanziieren, wenn und nur wenn

   isinstance(firstarg, type)
   

Somit ist die vollständige Abschaffung der impliziten Instanziierung nicht notwendig, um dieses Problem zu lösen.

Hässlichkeit der expliziten Instanziierung

Einige Befragte empfanden die explizit instanziierende Syntax als unschöner, insbesondere in Fällen, in denen keine Argumente an den Ausnahme-Konstruktor übergeben werden

raise TypeError()

Das Problem ist besonders akut, wenn die Ausnahme-Instanz selbst nicht von Interesse ist, d.h., wenn der einzige relevante Punkt der Ausnahmetyp ist

try:
    # ... deeply nested search loop ...
        raise Found
except Found:
    # ...

In solchen Fällen kann die Symmetrie zwischen raise und except die Absicht des Codes besser ausdrücken.

Guido meinte, dass die implizit instanziierende Syntax „ein bisschen schöner“ sei, selbst für Fälle mit einem einzigen Argument, da sie weniger Satzzeichen aufweist.

Performance-Strafe für Warnungen

Die Erfahrung mit der Verwarnung von apply() zeigt, dass die Verwendung des Warnrahmens eine signifikante Leistungsbeeinträchtigung mit sich bringen kann.

Code, der explizit instanziiert, wäre nicht betroffen, da die zur Bestimmung der Notwendigkeit einer Warnung erforderlichen Laufzeitprüfungen genau die sind, die benötigt werden, um festzustellen, ob überhaupt implizit instanziiert werden soll. Das heißt, solche Anweisungen verursachen bereits die Kosten dieser Prüfungen.

Code, der implizit instanziiert, würde hohe Kosten verursachen: Timing-Tests zeigen, dass das Ausgeben einer Warnung (ob unterdrückt oder nicht) etwa fünfmal länger dauert als das einfache Instanziieren, Auslösen und Abfangen einer Ausnahme.

Diese Strafe wird dadurch gemildert, dass raise-Anweisungen selten auf leistungsabhängigen Ausführungspfaden liegen.

Traceback-Argument

Nach dem jetzigen Vorschlag wäre es unmöglich, das Traceback-Argument von raise bequem mit allen Python 2.x-Versionen zu verwenden.

Für die Kompatibilität mit Versionen < 2.4 muss die Drei-Argument-Form verwendet werden; diese Form würde jedoch mit Versionen >= 2.4 Warnungen erzeugen. Diese Warnungen könnten unterdrückt werden, aber das ist umständlich, da die relevante Art der Warnung zur Kompilierzeit ausgegeben wird.

Wenn dieser PEP noch in Erwägung gezogen würde, würde diesem Einwand durch Verlängerung der Einführungsphase begegnet. Zum Beispiel könnten Warnungen zuerst in 3.0 ausgegeben und erst in einer späteren Version zu Fehlern werden.