mitmario.dev

Fehler lesen

PHP Sandbox 4 Min Lesezeit 3 BeispieleLektion 4 von 6

Fehlermeldungen sind keine Strafe, sondern der schnellste Weg zur Lösung. Man muss sie nur lesen können, und dafür reicht es zu wissen, welche drei Sorten es gibt und was jede von ihnen bedeutet.

Parse-Fehler: die Datei ist nie gestartet

Ein Parse-Fehler heißt, dass PHP deine Datei nicht einmal verstehen konnte. Es liest sie einmal komplett, bevor irgendetwas passiert, und wenn dabei etwas nicht aufgeht, hört es sofort auf.

Ein Parse-Fehler startet die Datei gar nicht erst
<?php

echo "Diese Zeile siehst du nie.\n";

$preis = 10 * 3
echo "Preis: $preis Euro\n";

Achte darauf, was nicht passiert: Die Ausgabe bleibt komplett leer, obwohl in der dritten Zeile ein völlig korrektes echo steht. Es ist nichts gelaufen, keine einzige Zeile.

Die Meldung dazu lautet syntax error, unexpected token "echo" und nennt Zeile 6. Das ist die Falle: In Zeile 6 ist alles in Ordnung. Der Fehler steckt in Zeile 5, dort fehlt das Semikolon. PHP liest weiter, bis es merkt, dass etwas nicht passt, und meldet die Stelle, an der es gemerkt hat, nicht die, an der es passiert ist.

Deshalb die Regel: Bei einem Parse-Fehler schau in die genannte Zeile und in die Zeile davor. Meistens fehlt eins von drei Dingen: ein Semikolon, eine schließende Klammer oder ein Anführungszeichen.

Ob eine Datei überhaupt startet, kannst du fragen, ohne sie laufen zu lassen: php -l index.php im Terminal prüft nur die Syntax. Bei diesem Beispiel steht danach dieselbe Meldung wie beim Lauf, dazu Errors parsing index.php, und nichts ist ausgeführt worden.

Fatal error: mittendrin ist Schluss

Ein Fatal error passiert erst beim Laufen. Die Datei ist in Ordnung, aber irgendwo verlangt sie etwas, das es nicht gibt.

Ein Fatal error bricht mitten im Lauf ab
<?php

echo "vorher\n";
echo grossschreiben("hallo") . "\n";
echo "nachher\n";

Hier siehst du den Unterschied zum Parse-Fehler sofort: vorher steht in der Ausgabe, nachher nicht. Das Programm ist bis Zeile 4 gekommen und dort gestorben. Die Funktion grossschreiben gibt es in PHP nicht, sie heißt strtoupper. Und php -l index.php sagt zu dieser Datei No syntax errors detected: Syntaktisch ist sie in Ordnung, der Fehler zeigt sich erst beim Laufen.

Unter der Meldung stehen ein paar Zeilen mit Stack trace. Die brauchst du hier noch nicht; sie werden interessant, sobald deine Funktionen sich gegenseitig aufrufen und du wissen willst, wer wen gerufen hat. Fürs Erste zählt die erste Zeile: was passiert ist und wo.

Warning: das Programm läuft weiter und liefert Unsinn

Und jetzt die Sorte, die wirklich wehtut.

Eine Warning lässt das Programm weiterlaufen
<?php

$daten = ["name" => "Kaffee"];

echo "Artikel: " . $daten["name"] . "\n";
echo "Menge: " . $daten["menge"] . "\n";
echo "fertig\n";

Das Programm läuft komplett durch und meldet am Ende fertig. Trotzdem stimmt etwas nicht: Bei Menge: steht nichts, denn den Schlüssel menge gibt es in dem Array gar nicht. PHP schreibt eine Warning und macht weiter, als wäre nichts.

Genau das macht Warnings gefährlicher als die anderen beiden. Ein Parse-Fehler und ein Fatal error fallen auf, weil nichts mehr geht. Eine Warning fällt niemandem auf, bis irgendwann jemand eine Rechnung über 0 Euro bekommt.

Die Regel für diesen Kurs ist deshalb streng: Eine Warning ist ein Fehler. Sie wird behoben und nicht weggeschaut. In den Aufgaben steht dafür oft eine eigene Prüfung, die verlangt, dass auf dem Fehlerkanal wirklich nichts mehr liegt.

Wo die Meldungen landen

Ein Punkt, der später wichtig wird: In diesem Kurs stehen Fehlermeldungen nicht in der Ausgabe, sondern auf dem Fehlerkanal. Das sind zwei getrennte Kanäle, und im Terminal siehst du sie untereinander.

Das ist eine Einstellung und keine Naturgewalt. Sie ist so gewählt, damit deine Ausgabe sauber bleibt: Eine Warning mitten in der Programmausgabe würde jeden genauen Vergleich zerschießen. Auf einem eigenen Server kannst du das umstellen, und in Abschnitt 15 machst du das auch einmal, um zu sehen, warum man es im Betrieb besser lässt.

Die Zahl am Ende

Jedes Programm hinterlässt beim Beenden eine Zahl, den Exit-Code. Sie beantwortet genau eine Frage: hat es geklappt oder nicht.

Ein Programm, das durchläuft, endet mit 0. Ein Parse-Fehler und ein Fatal error geben in PHP beide 255. Eine Warning ändert den Exit-Code nicht, das Programm ist ja ordentlich zu Ende gegangen, und auch das ist ein Grund, warum man sie leicht übersieht.

Zu sehen bekommst du die Zahl nirgends von selbst, dafür auf Nachfrage: php index.php; echo $? im Terminal. Das Semikolon trennt zwei Befehle, $? ist der Exit-Code des letzten. Probier es mit allen drei Beispielen von oben, dann hast du die Zahlen einmal selbst gesehen: zweimal 255, einmal 0.

Zum Mitnehmen

Ein Parse-Fehler heißt, dass gar nichts gelaufen ist. Ein Fatal error bricht mittendrin ab. Eine Warning bricht nichts ab, und genau deshalb ist sie die gefährlichste von den dreien.

Jetzt du

Basis Konto, kostenlos

Zu dieser Lektion gehört eine Aufgabe. Du schreibst den Code selbst, und nach jedem Lauf sagt dir eine Prüfliste, was schon stimmt.

Dafür brauchst du das Basis Konto. Es kostet nichts, und ein Passwort gibt es auch nicht.

In diesem Kurs läuft dein Code auf einem Server. Dafür hat das Basis Konto 1 Stunde im Monat, mehr Zeit gibt es mit dem Premium Konto.

Was in dieser Lektion steckt

  • Artikel mit 3 Beispielen zum Ausprobieren

    Steht hier, ohne Konto lesbar.

  • Aufgabe, dein Code läuft auf einem Server

    Öffnet sich mit dem Basis Konto.