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

Netzwerk-Portfolio für das KI-Zeitalter

Huawei stellt auf der Connect Europe 2024 in Paris mit Xinghe Intelligent Network eine erweiterte…

1 Tag ago

Internet-Tempo in Deutschland: Viel Luft nach oben

Höchste Zeit für eine schnelle Kupfer-Glas-Migration. Bis 2030 soll in Deutschland Glasfaser flächendeckend ausgerollt sein.

1 Tag ago

Erste Entwickler-Preview von Android 16 verfügbar

Schon im April 2025 soll Android 16 den Status Plattformstabilität erreichen. Entwicklern gibt Google danach…

1 Tag ago

Kaspersky warnt vor Cyberangriff auf PyPI-Lieferkette

Die Hintermänner setzen KI-Chatbot-Tools als Köder ein. Opfer fangen sich den Infostealer JarkaStealer ein.

2 Tagen ago

Digitale Produkte „cyberfit“ machen

Vernetzte Produkte müssen laut Cyber Resilience Act über Möglichkeiten zur Datenverschlüsselung und Zugangsverwaltung verfügen.

2 Tagen ago

Google schließt schwerwiegende Sicherheitslücken in Chrome 131

Das jüngste Update für Windows, macOS und Linux stopft drei Löcher. Eine Anfälligkeit setzt Nutzer…

2 Tagen ago