Eigener Error-Handler mit PHP

Zuerst die Grundlagen. PHP kennt drei grundlegende Fehlertypen, die nach ihrem Schweregrad abgestuft sind: Benachrichtigungen (notices), Warnungen (warnings) und Fehler (errors beziehungsweise fatals). Normalerweise führen Warnungen und Benachrichtigungen nicht zum Abbruch eines Scripts, fatal errors hingegen weisen auf schwerwiegende Fehler hin (zum Beispiel den Aufruf einer nicht existierenden Funktion oder eine Referenz auf ein nicht vorhandenes Objekt), die zum sofortigen Abbruch des Scripts führen. Solche Fehler können schon beim Starten des Scripts, beim Parsen, Kompilieren, zur Laufzeit oder nach Bedarf vom Script erzeugt werden.

Schlüsselbegriffe wie E_NOTICE, E_ERROR und so weiter beziehen sich auf die unterschiedlichen Fehlertypen und -stufen. Eine vollständige Liste samt der zugehörigen Bitmasken findet sich im PHP-Manual.

Für jedes Script wird die Fehleranzeige mithilfe der Funktion error_reporting() kontrolliert. Diese Funktion erwartet eine Liste von Parametern, die den einzelnen Fehlerstufen entsprechen, die berichtet werden sollen. Wie dies in der Praxis aussieht, zeigt das folgende Script (Listing A), welches nur Warnungen und Fehler meldet:

Listing A

Man vergleiche dies mit dem Script in Listing B, wo sämtliche Fehler – selbst die schwerwiegenden – verborgen werden:

Listing B

Oder mit diesem Script (Listing C), wo alle Fehler angezeigt werden, auch einfache Benachrichtigungen:

Listing C

Wie die obigen drei kurzen Beispiele illustrieren, ist die Funktion error_reporting() wichtig für die Kontrolle, welche Fehlermeldungen der Benutzer überhaupt zu Gesicht bekommt. Das Schlüsselwort lautet hier „zu Gesicht bekommt“, denn nur weil ein Fehler nicht angezeigt wird, bedeutet dies nicht, dass er nicht aufgetreten ist. Das heißt, auch wenn überhaupt keine Fehler berichtet werden, wird ein schwerwiegender Fehler (zum Beispiel ein falscher Funktionsaufruf) die Ausführung des Scripts abbrechen, nur dass der Benutzer keine Fehlermeldung zu sehen bekommt, die ihn darüber informiert.

Das folgende Beispiel (Listing D) illustriert dies:

Listing D

Hier tritt ein schwerwiegender Fehler zwischen den beiden Aufrufen von echo() auf, wodurch die Ausführung des Scripts an der entsprechenden Stelle abgebrochen wird. Aber weil alle Fehlermeldungen deaktiviert wurden, erfährt der Benutzer hiervon nichts und nimmt womöglich an, dass das Script erfolgreich ausgeführt wurde. Offensichtliches Fazit: Das Deaktivieren von Fehlermeldungen ist eine höchst gefährliche Sache, weil es zu irrigen Annahmen darüber führen kann, ob ein Prozess erfolgreich abgeschlossen wurde oder nicht.

Tipp: Wenn man error_reporting() ohne Parameter aufruft, wird der aktuelle Status des Fehler-Reportings zurückgegeben.

Page: 1 2 3 4 5

ZDNet.de Redaktion

Recent Posts

Cyberbedrohungen: Deutschland ist digital nur „bedingt abwehrbereit“

Ein Viertel der Entscheidungsträger in Politik und Verwaltung spricht sogar vom Fehlen jeglicher Abwehrbereitschaft. Die…

6 Tagen ago

Ransomware-Angriffe führen häufig auch zu Datenverlusten

Der Anteil steigt der Vorfälle mit Datenverlusten steigt 2024 deutlich an. Einige Unternehmen melden nach…

6 Tagen ago

Identitätsdiebstahl post mortem – Deepfakes aus dem Jenseits?

60 Prozent der Deutschen befürworten, dass Onlinenutzer per Testament darüber verfügen, was im Todesfall mit…

7 Tagen ago

ISG-Studie: Hohe SASE-Nachfrage treibt deutschen SDN-Markt

Werkzeuge und Architekturkonzepte wissen zu überzeugen. Zudem wächst die Zahl der Dienstleister mit ausreichender Umsetzungsexpertise.

7 Tagen ago

Studie: Cyberattacken haben auch psychische Auswirkungen auf Opfer

Eine Studie von Akamai deckt Folgen wie emotionaler Stress und Rückgang des Selbstwertgefühls auf. Ein…

7 Tagen ago

Windows 11 24H2: Probleme mit dem System File Checker

Das Tool liefert wiederholt Falschmeldungen. Es erkennt bei einem Scan bereits reparierte Systemdateien weiterhin als…

7 Tagen ago