Kryptische Fehlermeldungen in PHP
Mit den Jahren der Programmierung stößt man unwiderruflich auch auf komische Fehlermeldungen in PHP, die auch nach dem 3. Mal lesen unverständlich sind und die Fehlerquelle unklar bleibt. Hier möchte ich einige Fehlermeldungen auflisten an die ich mich erinnern kann, und auch kurz notieren wann und wieso sie auftreten.
Ich nehme mich da selbst nicht aus, in meinen Applikationen sind die Fehlermeldungen auch nicht immer sehr aussagekräftig, vor allem wenn sie sehr selten oder „nie“ auftreten sollten, von daher wird hier niemand an den Pranger gestellt, es soll nur helfen einige interessante Meldungen zu verstehen:
- Fatal error: Exception thrown without a stack frame in Unknown on line 0
Mein Favorit wenn es darum ging an Fehlermeldungen zu verzweifeln. Die Fehlermeldung sagt also dass PHP in der Datei Unknown in Zeile 0 keinen Stack-Frame erstellen konnte als eine Exception geworfen wurde. Prima!
Der Fehler trat auf wenn PHP noch nicht richtig, bzw. nicht mehr richtig läuft oder sich in einigen magischen Methoden befindet. PHP konnte anscheinend nicht feststellen wo im Programmfluss es gerade steckte.
Untersuchen sollte man die Stellen wo in einem Konstruktor, einem Destruktor oder einem Exception-/Error-Handler eine Exception geworfen wird. Entweder man entfernt die Exceptions und löst das Problem anders, oder fügt dort jeweils einen try-catch-Block hinzu, sodass die Exception nicht geworfen wird.
Ich habe diese 3 Möglichkeiten gerade nochmal versucht nachzustellen mit PHP 5.3.8, aber mittlerweile kommen da aussagekräftige Fehlermeldungen mit Datei- und Zeilenangaben. Die kryptische Fehlermeldung scheint also irgendwann (vielleicht zum 5.3.0 Release?) ersetzt worden zu sein. Schade 😉 - Fatal error: Can’t use function return value in write context
Dieser Fehler ist auch etwas schwer zu verstehen wenn man noch nicht jahrelang programmiert, aber kann nur in 2 mir bekannten Fällen auftreten, und zwar bei der Verwendung von isset() oder empty().if (empty(isWorkDone())) { echo "done"; }Beiden Funktionen müssen als Parameter jeweils Variablen übergeben werden. Wenn man ihnen einen Funktionsaufruf übergibt (was ja normalerweise kein Problem ist) spucken sie die oben genannte Fehlermeldung aus. Man muss also das Ergebnis des Funktionsaufrufs erst in eine Variable speichern und dann an isset() oder empty() übergeben.
Es gibt ein RFC von Nikita Popov mit dem Vorschlag diese Einschränkung aufzuheben, das Voting läuft noch. - Fatal error: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM
Dieser Fehler trat früher auf wenn man eine nicht-statische Methode statisch aufgerufen hat, also mit einem ::. Und damit ist das Rätsel auch quasi schon gelöst, denn PAAMAYIM_NEKUDOTAYIM ist hebräisch und heißt „Doppel-Doppelpunkt“ und steht damit für den Scope-Resolution-Operator. Warum schreibe ich früher? Weil diese Meldung mittlerweile geändert wurde, in aktuellen Versionen von PHP erhält man die aussagekräftigere Fehlermeldung
Non-static method Audi::drive() should not be called staticallyclass Audi { public function drive() { echo 'brumm brumm'; } } Audi::drive();Mit wirklich falschem Code kann man ihn aber nach wie vor hervorlocken, beispielsweise:
$var = ;
Fatal error: Parse error: syntax error, unexpected ‚;‘, expected T_PAAMAYIM_NEKUDOTAYIM
Heutzutage zeigen gute IDEs alle diese Fehler bereits beim Programmieren an, vor wenigen Jahren war das noch nicht der Fall. Oder kann jemand für aktuelle Versionen von Netbeans, Eclipse, Zend Studio oder Komodo etc. sagen dass diese Fehler nicht erkannt werden?
Ihr habt ja wahrscheinlich auch schon so einiges gesehen an Fehlermeldungen. Was sind eure kuriosesten oder unverständlichsten Fehlermeldungen aus dem Webentwickler-Umfeld?
Der T_PAAMAYIM_NEKUDOTAYIM Fehler kann auch auftreten, wenn man versucht eine statische Methode oder Variable aufzurufen und der Klassen Name ebenfalls als Variable angegeben ist.
z.B.
$classname = ‚Foo‘;
$classname::bar();
Michael Steinmann
8 Mai 12 at 12:14
@Michael Steinmann: Welche PHP-Version nutzt du? Genau das ist der Fall den ich nicht mehr nachvollziehen kann, ich meine mich aber daran zu erinnern dass das früher mal genau diesen Fehler ausgegeben hat. Ich habe hier nur 5.3.9 zur Hand.
Michael Kliewe
8 Mai 12 at 12:25
@Michael Kliewe: Das funktioniert soweit ich weiß seit PHP 5.3, vorher wurde der genannte Fehler geworfen. Dürfte also bei dem anderen Michael an einer älteren PHP-Version liegen.
Jan Thurau
8 Mai 12 at 13:00
@Michael Kliewe: Dieser Fehler tritt noch bei der Version PHP 5.2.10 auf.
Michael Steinmann
8 Mai 12 at 14:20
Kann es sein, dass ich den Artikel vor ein paar Tagen schon mal auf Englisch gelesen hab? ^_^
Oliver
8 Mai 12 at 14:25
@Oliver: Wahrscheinlich hier: http://epixa.com/2012/04/common-cryptic-php-errors.html
Finde aber trotzdem Klasse das Michael sich die Arbeit gemacht hat dies ins deutsche zu übersetzen und dann noch mit ein paar Code-Snippets zu pimpen.
MBDealer
8 Mai 12 at 15:04
Sick, einfach einen fremden Artikel übersetzt veröffentlichen.
Michael
8 Mai 12 at 16:39
Da scheine ich ja gar nicht so falsch zu liegen mit meiner Favoritenliste.
Ich bin auf das Thema durch Nikita’s RFC gekommen vor 4 Wochen, die Diskussion in der PHP-Internals-Mailingliste (und das Voting) läuft auch noch. Die Fehlermeldung bzgl. isset()/empty() ist diejenige die ich ab und zu noch gesehen habe die letzten Monate. Die hebräische Fehlermeldung hatte ich vorher noch nie gesehen, kam zutage bei der Recherche zu den PHP Easter Eggs Anfang April (wobei ich das nicht als Easter-Egg sehe, sie ist einfach nur kurios) und in dem epischen PHP-Rant-Klassiker von Anfang April „PHP – a fractal of bad design“:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Der Error „in File Unknown Line 0“ ist die die einem immer im Gedächtnis bleibt wenn man mal einige Stunden deshalb verloren hat, wurde ja dankenswerterweise mittlerweile verbessert als ich es ausprobiert habe. Wenn man nichtmal Datei- oder Zeileninformationen hat hängt man echt maximal in der Luft.
Hab die letzten Wochen noch drüber nachgedacht weil ich dachte ich würde mehr finden, aber irgendwie sind mir nicht mehr eingefallen als die drei, die so schlecht gewählt sind oder wo ich länger drüber nachdenken mußte wo nun das Problem liegt.
Eine Exception innerhalb einer Exception wie sie Court in seinem Artikel erwähnt ist natürlich auch interessant, hab ich noch nie drüber nachgedacht (wer wirft auch Exceptions innerhalb von Exceptions??). Hab leider keine alte PHP Version hier um das zu verifizieren. Der Grep-Befehl könnte auch interessant sein wenn man nach dem Fehler sucht. Besser ist es aber (hätt ich auch noch schreiben sollen oben) wenn man eine neuere PHP Version nimmt, dann bekommt man Details mit Dateinamen und Zeilennummern, ist wahrscheinlich einfacher als alle Konstruktoren, Destruktoren etc. zu durchsuchen.
@MBDealer: Ich habe mich nicht als Übersetzer versucht, kannte den Artikel noch nicht. Hab bisher noch keine Artikel übersetzt, Artikel die ich finde und die interessant sind packe ich in die Linkpools die ich ab und zu am Wochenende veröffentliche. Ich gehe davon aus dass ihr alle Englisch versteht und ich mir nicht die Mühe mache das zu übersetzen. Oder ist dafür Bedarf da?
Michael Kliewe
8 Mai 12 at 16:56
@Michael Kliewe: Ich wollte dir auch keinesfalls unterstellen das du den Artikel von irgendwo her übersetzt hast, mir kam halt der Inhalt, genau so wie es Oliver erging so bekannt vor. Bis heute kannte ich deinen Blog auch noch nicht. Wenn es so ankam entschuldige ich mich hiermit dafür.
Hast jedenfalls einen neuen Leser dazu bekommen, dank der Facebook-Seite vom PHP Magazin.
MBDealer
8 Mai 12 at 22:02
Das Problem bei Fehler ist oft die Auswirkung und Ursache. Selbst Ärzte wissen manchmal oft nicht den unterschied *grins*.
Wenn man irgendwo z.B. ein „select from * table“ setzt und es wird erst bei der Datenbank Klasse ein Fehler geworfen, ist es oft schwer diesen Fehler an seinen Ursprung zurück zu verfolgen. Gerade bei schlechten Software Designs kann man da schon mal ein bisschen an der falschen Stelle suchen.
T-Rex
9 Mai 12 at 09:57
Fatal error: Can’t use function return value in write context
Man sollte an dieser Stelle erwähnen, dass sowohl isset() als auch empty() Sprachkonstrukte und ebend KEINE Funktionen sind. Daher tritt das Problem auf.
Fabian Blechschmidt
9 Mai 12 at 10:21
@Fabian Blechschmidt: Ich glaube nicht dass es daran liegt dass es ein Sprachkonstrukt ist, denn dann dürfte man bei echo, require, die() etc. ja auch keine Funktionen übergeben. Das funktioniert aber wunderbar.
php -r „function getfunctionname() {return ‚bla.php‘;} require getfunctionname();“
Liste der Sprachkonstrukte:
http://php.net/manual/en/reserved.keywords.php
Michael Kliewe
9 Mai 12 at 10:45
War es nicht auch so, das die „Exception thrown without a stack frame in Unknown on line 0“ Fehlermeldung erscheint, wenn man in einem shutdown hook z.B. auf bereits aufgeräumte Ressourcen zugreifen will? Oder eben dort schlicht eine Exception schmeisst … sorry, bin gerade zu faul zum Testen.
Kevin
9 Mai 12 at 17:32
[…] Kryptische Fehlermeldungen in PHP | PHP Gangsta […]
Linkhub – Woche 19-2012
14 Mai 12 at 18:43