Verwirrende Menge von OS-bezogenen Exceptions

OS-bezogene (oder Systemaufruf-bezogene) Ausnahmen sind derzeit eine Vielfalt von Klassen, die in den folgenden Unterhierarchien angeordnet sind

+-- EnvironmentError
    +-- IOError
        +-- io.BlockingIOError
        +-- io.UnsupportedOperation (also inherits from ValueError)
        +-- socket.error
            +-- socket.gaierror
            +-- socket.herror
            +-- socket.timeout
    +-- OSError
        +-- VMSError
        +-- WindowsError
    +-- mmap.error
+-- select.error

Während einige dieser Unterscheidungen durch Implementierungsüberlegungen erklärt werden können, sind sie auf einer höheren Ebene oft nicht sehr logisch. Die Trennlinie zwischen OSError und IOError zum Beispiel ist oft verschwommen. Betrachten Sie Folgendes

>>> os.remove("fff")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 2] No such file or directory: 'fff'
>>> open("fff")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'fff'

Die gleiche Fehlerbedingung (eine nicht existierende Datei) wird als zwei verschiedene Ausnahmen klassifiziert, abhängig davon, welche Bibliotheksfunktion aufgerufen wurde. Der Grund dafür ist, dass das os-Modul ausschließlich OSError (oder seine Unterklasse WindowsError) auslöst, während das io-Modul hauptsächlich IOError auslöst. Der Benutzer interessiert sich jedoch für die Art des Fehlers, nicht dafür, aus welchem Teil des Interpreters er stammt (da letzteres beim Lesen der Traceback-Nachricht oder des Anwendungscodes offensichtlich ist).

Tatsächlich ist es schwer vorstellbar, eine Situation, in der OSError abgefangen werden sollte, aber nicht IOError, oder umgekehrt.

Ein weiterer Beweis für die Mehrdeutigkeit dieser Segmentierung ist, dass die Standardbibliothek selbst manchmal Probleme hat, sich zu entscheiden. Zum Beispiel löst im select-Modul ähnliche Fehler select.error, OSError oder IOError aus, je nachdem, ob Sie select(), ein poll-Objekt, ein kqueue-Objekt oder ein epoll-Objekt verwenden. Dies macht den Benutzercode unnötig kompliziert, da er darauf vorbereitet sein muss, verschiedene Ausnahmetypen abzufangen, je nachdem, welche genaue Implementierung eines einzelnen Primitivs er zur Laufzeit wählen möchte.

Was WindowsError betrifft, so scheint es eine sinnlose Unterscheidung zu sein. Erstens existiert es nur auf Windows-Systemen, was mühsamen Kompatibilitätscode in plattformübergreifenden Anwendungen erfordert (solcher Code findet sich in Lib/shutil.py). Zweitens erbt es von OSError und wird für ähnliche Fehler wie OSError auf anderen Systemen ausgelöst. Drittens muss der Benutzer, der auf Low-Level-Ausnahmespezifika zugreifen möchte, ohnehin das Attribut errno oder winerror untersuchen.

Fehlende granulare Exceptions

Die aktuelle Vielfalt von OS-bezogenen Ausnahmen erlaubt es dem Benutzer nicht, gewünschte Fehlertypen einfach zu filtern. Betrachten Sie als Beispiel die Aufgabe, eine Datei zu löschen, wenn sie existiert. Das LBYL-Idiom (Look Before You Leap) leidet unter einer offensichtlichen Race Condition

if os.path.exists(filename):
    os.remove(filename)

Wenn eine Datei mit dem Namen filename von einem anderen Thread oder Prozess zwischen den Aufrufen von os.path.exists und os.remove erstellt wird, wird sie nicht gelöscht. Dies kann zu Fehlern in der Anwendung oder sogar zu Sicherheitsproblemen führen.

Daher besteht die Lösung darin, zu versuchen, die Datei zu entfernen und den Fehler zu ignorieren, wenn die Datei nicht existiert (ein Idiom, das als „Besser um Vergebung bitten als um Erlaubnis fragen“ (EAFP) bekannt ist). Sorgfältiger Code würde wie folgt aussehen (was sowohl unter POSIX als auch unter Windows-Systemen funktioniert)

try:
    os.remove(filename)
except OSError as e:
    if e.errno != errno.ENOENT:
        raise

oder sogar

try:
    os.remove(filename)
except EnvironmentError as e:
    if e.errno != errno.ENOENT:
        raise

Das ist viel Tipparbeit, und zwingt den Benutzer auch, sich die verschiedenen kryptischen Mnemonics aus dem errno-Modul zu merken. Es auferlegt eine zusätzliche kognitive Belastung und wird ziemlich schnell ermüdend. Folglich schreiben viele Programmierer stattdessen den folgenden Code, der Ausnahmen zu breit unterdrückt

try:
    os.remove(filename)
except OSError:
    pass

os.remove kann eine OSError nicht nur auslösen, wenn die Datei nicht existiert, sondern auch in anderen möglichen Situationen (z. B. der Dateiname verweist auf ein Verzeichnis oder der aktuelle Prozess hat keine Berechtigung, die Datei zu löschen), die alle Fehler in der Anwendungslogik anzeigen und daher nicht unterdrückt werden sollten. Was der Programmierer stattdessen schreiben möchte, ist etwas wie

try:
    os.remove(filename)
except FileNotFoundError:
    pass

Begründung

Dieser erste Schritt präsentiert dem Benutzer nicht nur eine einfachere Landschaft, wie im Abschnitt Begründung erläutert, sondern ermöglicht auch eine bessere und vollständigere Lösung von Schritt 2 (siehe Voraussetzung).

Die Begründung für die Beibehaltung von OSError als offiziellen Namen für generische OS-bezogene Ausnahmen ist, dass diese präzise generischer ist als IOError. EnvironmentError ist umständlicher zu tippen und auch viel weniger bekannt.

Die Übersicht in Anhang B zeigt, dass IOError heute die dominante Fehlerart in der Standardbibliothek ist. Was Python-Code von Drittanbietern betrifft, so zeigt die Google Code Search, dass IOError in Benutzercode zehnmal beliebter ist als EnvironmentError und dreimal beliebter als OSError [3]. Ohne die Absicht, IOError mittelfristig zu verwerfen, ist die geringere Beliebtheit von OSError jedoch kein Problem.

Exception-Attribute

Da WindowsError in OSError zusammengeführt wird, erhält letztere unter Windows ein winerror-Attribut. Es wird unter Situationen auf None gesetzt, in denen es nicht aussagekräftig ist, wie es bereits bei den Attributen errno, filename und strerror der Fall ist (z. B. wenn OSError direkt von Python-Code ausgelöst wird).

Deprecation von Namen

Die folgenden Absätze skizzieren eine mögliche Strategie zur Deprecation alter Exception-Namen. Es wurde jedoch beschlossen, sie vorerst als Aliase beizubehalten. Diese Entscheidung könnte rechtzeitig für Python 4.0 überarbeitet werden.

Voraussetzung

Schritt 1 ist eine lose Voraussetzung dafür.

Voraussetzung, da einige errnos derzeit verschiedenen Exception-Klassen zugeordnet werden können: Zum Beispiel kann ENOENT sowohl OSError als auch IOError zugeordnet sein, abhängig vom Kontext. Wenn wir die nützliche Kompatibilität nicht brechen wollen, können wir keine except OSError (oder IOError) Verfehlungen beim Abgleich einer Ausnahme zulassen, wo es heute erfolgreich wäre.

Lose, da wir uns für eine partielle Lösung von Schritt 2 entscheiden könnten, wenn bestehende Exception-Klassen nicht zusammengeführt werden: Zum Beispiel könnte ENOENT eine hypothetische FileNotFoundError auslösen, wo zuvor eine IOError ausgelöst wurde, aber andernfalls weiterhin OSError auslöst.

Die Abhängigkeit von Schritt 1 könnte vollständig entfernt werden, wenn die neuen Unterklassen Mehrfachvererbung verwenden, um mit allen bestehenden Superklassen (oder zumindest OSError und IOError, die die am weitesten verbreiteten sind) übereinzustimmen. Dies würde jedoch die Hierarchie komplizierter und damit für den Benutzer schwerer verständlich machen.

Neue Exception-Klassen

Die folgende vorläufige Liste von Unterklassen, zusammen mit einer Beschreibung und der Liste der ihnen zugeordneten errnos, wird zur Diskussion gestellt

• FileExistsError: Versuch, eine Datei oder ein Verzeichnis zu erstellen, das bereits existiert (EEXIST)
• FileNotFoundError: für alle Umstände, unter denen eine Datei oder ein Verzeichnis angefordert wird, aber nicht existiert (ENOENT)
• IsADirectoryError: Dateioperation (open(), os.remove()...) auf einem Verzeichnis angefordert (EISDIR)
• NotADirectoryError: Verzeichnisoperation auf etwas anderem angefordert (ENOTDIR)
• PermissionError: Versuch, eine Operation ohne ausreichende Zugriffsrechte durchzuführen - z. B. Dateisystemberechtigungen (EACCES, EPERM)
• BlockingIOError: eine Operation würde auf einem Objekt (z. B. Socket) blockieren, das für den nicht-blockierenden Betrieb eingestellt ist (EAGAIN, EALREADY, EWOULDBLOCK, EINPROGRESS); dies ist die bestehende io.BlockingIOError mit erweiterter Rolle
• BrokenPipeError: Versuch, in eine Pipe zu schreiben, während das andere Ende geschlossen wurde, oder Versuch, in einen Socket zu schreiben, der zum Schreiben heruntergefahren wurde (EPIPE, ESHUTDOWN)
• InterruptedError: ein Systemaufruf wurde durch ein eingehendes Signal unterbrochen (EINTR)
• ConnectionAbortedError: Verbindungsversuch vom Peer abgebrochen (ECONNABORTED)
• ConnectionRefusedError: Verbindung vom Peer zurückgewiesen (ECONNREFUSED)
• ConnectionResetError: Verbindung vom Peer zurückgesetzt (ECONNRESET)
• TimeoutError: Verbindung zeitüberschritten (ETIMEDOUT); dies kann als generische Timeout-Ausnahme neu klassifiziert werden und ersetzt socket.timeout und ist auch für andere Arten von Timeouts nützlich (z. B. bei Lock.acquire())
• ChildProcessError: Operation auf einem Kindprozess fehlgeschlagen (ECHILD); dies wird hauptsächlich von der wait()-Familie von Funktionen ausgelöst.
• ProcessLookupError: der angegebene Prozess (identifiziert z. B. durch seine Prozess-ID) existiert nicht (ESRCH).

Darüber hinaus wird die folgende Exception-Klasse zur Aufnahme vorgeschlagen

• ConnectionError: eine Basisklasse für ConnectionAbortedError, ConnectionRefusedError und ConnectionResetError

Die folgende Zeichnung versucht, die vorgeschlagenen Ergänzungen zusammenzufassen, zusammen mit den entsprechenden errno-Werten (sofern zutreffend). Die Wurzel der Unterhierarchie (OSError, unter der Annahme, dass Schritt 1 vollständig akzeptiert wird) wird nicht gezeigt

+-- BlockingIOError        EAGAIN, EALREADY, EWOULDBLOCK, EINPROGRESS
+-- ChildProcessError                                          ECHILD
+-- ConnectionError
    +-- BrokenPipeError                              EPIPE, ESHUTDOWN
    +-- ConnectionAbortedError                           ECONNABORTED
    +-- ConnectionRefusedError                           ECONNREFUSED
    +-- ConnectionResetError                               ECONNRESET
+-- FileExistsError                                            EEXIST
+-- FileNotFoundError                                          ENOENT
+-- InterruptedError                                            EINTR
+-- IsADirectoryError                                          EISDIR
+-- NotADirectoryError                                        ENOTDIR
+-- PermissionError                                     EACCES, EPERM
+-- ProcessLookupError                                          ESRCH
+-- TimeoutError                                            ETIMEDOUT

Benennung

Verschiedene Namensstreitigkeiten können entstehen. Eine davon ist, ob alle Namen von Exception-Klassen auf „Error“ enden sollten. Dafür spricht die Konsistenz mit dem Rest der Exception-Hierarchie, dagegen die Kürze (insbesondere bei langen Namen wie ConnectionAbortedError).

Exception-Attribute

Um nützliche Kompatibilität zu erhalten, sollten diese Unterklassen immer noch angemessene Werte für die verschiedenen Exception-Attribute der Oberklasse setzen (z. B. errno, filename und optional winerror).

Implementierung

Da vorgeschlagen wird, dass die Unterklassen rein basierend auf dem Wert von errno ausgelöst werden, sollten nur geringe oder gar keine Änderungen in Erweiterungsmodulen (sowohl Standard- als auch Drittanbieter-) erforderlich sein.

Die erste Möglichkeit besteht darin, die Familie der PyErr_SetFromErrno()-Funktionen (PyErr_SetFromWindowsErr() unter Windows) anzupassen, um die entsprechende OSError-Unterklasse auszulösen. Dies würde jedoch keinen Python-Code abdecken, der OSError direkt auslöst, mit dem folgenden Idiom (gesehen in Lib/tempfile.py)

raise IOError(_errno.EEXIST, "No usable temporary file name found")

Eine zweite Möglichkeit, von Marc-Andre Lemburg vorgeschlagen, ist die Anpassung von OSError.__new__, um die entsprechende Unterklasse zu instanziieren. Dies hat den Vorteil, auch Python-Code wie den obigen abzudecken.

Namensraumverschmutzung

Die Verfeinerung der Exception-Hierarchie vergrößert den Wurzel- (oder Builtin-) Namensraum. Dies ist jedoch zu mäßigen, da

• nur eine Handvoll zusätzlicher Klassen vorgeschlagen wird;
• während Standard-Exception-Typen im Wurzelnamensraum leben, werden sie visuell dadurch unterschieden, dass sie die CamelCase-Konvention verwenden, während fast alle anderen Builtins Kleinbuchstaben verwenden (außer True, False, None, Ellipsis und NotImplemented)

Eine Alternative wäre, ein separates Modul bereitzustellen, das die feingranularen Ausnahmen enthält, aber das würde den Zweck der Förderung von vorsichtigem über unvorsichtigem Code zunichtemachen, da der Benutzer zuerst das neue Modul importieren müsste, anstatt auf bereits zugängliche Namen zuzugreifen.

Mustererkennung

Eine weitere Möglichkeit wäre die Einführung einer erweiterten Mustererkennungssyntax beim Abfangen von Ausnahmen. Zum Beispiel

try:
    os.remove(filename)
except OSError as e if e.errno == errno.ENOENT:
    pass

Mehrere Probleme mit diesem Vorschlag

• er führt neue Syntax ein, die vom Autor als schwerwiegendere Änderung im Vergleich zur Überarbeitung der Exception-Hierarchie angesehen wird
• er reduziert den Tippaufwand nicht wesentlich
• er entlastet den Programmierer nicht von der Last, sich errno-Mnemonics merken zu müssen

Gängige errnos mit OSError

• EBADF: fehlerhafter Dateideskriptor (bedeutet normalerweise, dass der Dateideskriptor geschlossen wurde)
• EEXIST: Datei oder Verzeichnis existiert
• EINTR: unterbrochener Funktionsaufruf
• EISDIR: ist ein Verzeichnis
• ENOTDIR: kein Verzeichnis
• ENOENT: keine solche Datei oder kein solches Verzeichnis
• EOPNOTSUPP: Operation wird auf Socket nicht unterstützt (mögliche Verwechslung mit dem bestehenden io.UnsupportedOperation)
• EPERM: Operation nicht erlaubt (bei Verwendung von z. B. os.setuid())

Gängige errnos mit IOError

• EACCES: Zugriff verweigert (für Dateisystemoperationen)
• EBADF: fehlerhafter Dateideskriptor (mit select.epoll); Leseoperation auf einem nur schreibbaren GzipFile oder umgekehrt
• EBUSY: Gerät oder Ressource beschäftigt
• EISDIR: ist ein Verzeichnis (beim Versuch zu öffnen())
• ENODEV: kein solches Gerät
• ENOENT: keine solche Datei oder kein solches Verzeichnis (beim Versuch zu öffnen())
• ETIMEDOUT: Verbindung zeitüberschritten

Gängige errnos mit socket.error

All diese Fehler können auch mit einer einfachen IOError verbunden sein, z. B. beim Aufruf von read() auf einem Socket-Dateideskriptor.

• EAGAIN: Ressource vorübergehend nicht verfügbar (bei einem nicht-blockierenden Socket-Aufruf außer connect())
• EALREADY: Verbindung bereits im Gange (bei einem nicht-blockierenden connect())
• EINPROGRESS: Operation im Gange (bei einem nicht-blockierenden connect())
• EINTR: unterbrochener Funktionsaufruf
• EISCONN: der Socket ist verbunden
• ECONNABORTED: Verbindung vom Peer abgebrochen (bei einem accept()-Aufruf)
• ECONNREFUSED: Verbindung vom Peer verweigert
• ECONNRESET: Verbindung vom Peer zurückgesetzt
• ENOTCONN: Socket nicht verbunden
• ESHUTDOWN: kann nach dem Herunterfahren des Transportendpunkts nicht senden
• EWOULDBLOCK: gleiche Gründe wie EAGAIN

Gängige errnos mit select.error

• EINTR: unterbrochener Funktionsaufruf

Über VMSError

VMSError wird vom Interpreter-Kern und der Standardbibliothek überhaupt nicht verwendet. Sie wurde als Teil der OpenVMS-Patches im Jahr 2002 von Jean-François Piéronne [4] hinzugefügt; die Motivation für die Aufnahme von VMSError war, dass sie von Drittanbieterpaketen ausgelöst werden könnte.

Interpreter-Kern

Behandlung von PYTHONSTARTUP löst IOError aus (aber der Fehler wird verworfen)

$ PYTHONSTARTUP=foox ./python
Python 3.2a0 (py3k:82920M, Jul 16 2010, 22:53:23)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Could not open PYTHONSTARTUP
IOError: [Errno 2] No such file or directory: 'foox'

PyObject_Print() löst IOError aus, wenn ferror() einen Fehler auf dem FILE * Parameter signalisiert (der im Quellcode immer stdout oder stderr ist).

Unicode-Kodierung und -Dekodierung mit der mbcs-Kodierung kann unter bestimmten Fehlerbedingungen WindowsError auslösen.

Standardbibliothek

>>> bz2.BZ2File("foox", "rb")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory
>>> bz2.BZ2File("LICENSE", "rb").read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: invalid data stream
>>> bz2.BZ2File("/tmp/zzz.bz2", "wb").read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: file is not ready for reading

>>> dbm.gnu.open("foox")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_gdbm.error: [Errno 2] No such file or directory

>>> imp.load_source("foo", "foo", 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

>>> open("Python/", "r")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 21] Is a directory: 'Python/'

>>> open("LICENSE").write("bar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: not writable
>>> io.StringIO().fileno()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: fileno
>>> open("LICENSE").seek(1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: can't do nonzero cur-relative seeks

>>> f = open("LICENSE")
>>> os.close(f.fileno())
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor

>>> f = open("LICENSE")
>>> next(f)
'A. HISTORY OF THE SOFTWARE\n'
>>> f.tell()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: telling position disabled by next() call

>>> mmap.mmap(123, 10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
mmap.error: [Errno 9] Bad file descriptor
>>> mmap.mmap(os.open("/tmp", os.O_RDONLY), 10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
mmap.error: [Errno 13] Permission denied

>>> fd = os.open("LICENSE", os.O_RDONLY)
>>> m = mmap.mmap(fd, 16384)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 5] Accès refusé
>>> sys.last_value.errno
13
>>> errno.errorcode[13]
'EACCES'

>>> m = mmap.mmap(-1, 4096)
>>> m.resize(16384)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 87] Paramètre incorrect
>>> sys.last_value.errno
22
>>> errno.errorcode[22]
'EINVAL'

>>> ossaudiodev.open("foo", "r")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: 'foo'

>>> readline.read_history_file("foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory
>>> readline.read_init_file("foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory
>>> readline.write_history_file("/dev/nonexistent")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied

>>> signal.alarm(1); select.select([], [], [])
0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
select.error: (4, 'Interrupted system call')
>>> e = sys.last_value
>>> e
error(4, 'Interrupted system call')
>>> e.errno == errno.EINTR
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'error' object has no attribute 'errno'
>>> e.args[0] == errno.EINTR
True