Warum man nachts nicht programmieren sollte!

Heute nacht wollte ich endlich wieder an meinem Projekt, das auf meinem Framework basiert, weiterarbeiten. Da PHP seit Version 5 die heiß ersehnten Type Hints untertützt, wollte ich diese natürlich benutzen!

Was sind Type Hints?

Sogenannte Type Hints sind in einer schwach Typisierten Sprache wie PHP eine Seltenheit. Man kann damit in einer Methode / Funktion in der Parameterliste angeben, welchen Typ ein Parameter haben soll. Momentan ist dies leider noch nicht für skalare Datentypen (Integer, Float, …) verfügbar. Arrays und Objekte können allerdings erzwunden werden.

public function typehinttest(array $dasIstImmerEinArray = array())

Der Parameter dasIstImmerEinArray wird ein optionaler Parameter. Es ist aber kein anderer Datentyp als Array möglich. Das gleiche geht auch mit Objekten. Man muss den Klassennamen angeben, von dem das Objekt eine Instanz ist. Auch Elternklassen gelten hier!

Das war jetzt ein kleiner Exkurs, jetzt zurück zum eigentlichen Thema!

Letzte Woche gab es einen Artikel über den Debugger

Ich habe euch vor ein paar Tagen von meinem FW_Debugger berichtet. Dieser Debugger war indirekt an meiner stundenlangen Fehlersuche schuld. Den entscheidenen Hinweis gab mir Combie aus dem PHPForum in diesem Thread.

Mein Problem war, dass ich bei einem Parameter, der ein Array sein muss, auch einen String angeben konnte. PHP zeigte mir keine Fehlermeldung an und auch in den Errorlogs war kein Eintrag zu finden.

Wenn bei einem Typehint ein nicht passender Parameter angegeben wird, reagiert PHP mit einem Catchable Fatal Error, ein E_RECOVERABLE_ERROR. Dieser wurde wie erwartet an meinen Errorlogger weitergegeben, ABER jetzt kommt der Fehler. Seht euch diesen Code an:

FW_Debugger::registerErrorHandler();


$request =  FW_Http_Request::getInstance();
$response = FW_Http_Response::getInstance();

$frontController = FW_FrontController::getInstance();
//----------------------------------------------------
// der zweite Parameter darf kein String sein. Er muss ein Array sein!
//----------------------------------------------------
$frontController->addSubController("Menu", "index");

$d = FW_Debugger::getInstance();
$d->addDebugger("file_errors", new FW_Debugger_File("../logs/errors.log", array(E_ERROR, E_USER_ERROR)));
$d->addDebugger("file_warnings", new FW_Debugger_File("../logs/warnings.log", array(E_WARNING, E_USER_WARNING)));
$d->addDebugger("file_notices", new FW_Debugger_File("../logs/notices.log", array(E_NOTICE, E_USER_NOTICE)));
$d->addDebugger("file_others", new FW_Debugger_File("../logs/others.log", array(E_STRICT, E_RECOVERABLE_ERROR, E_PARSE)));
$d->addDebugger("bildschirm", new FW_Debugger_Screen(array(E_ALL)));

Der Fehler fällt einem nicht auf den ersten Blick auf. Bei genauerer Überlegung jedoch schon.
Der Errorhandler wird ganz oben registriert. Damit wird der internet Errorhandler von PHP ausgeschaltet.
Standartmäßig loggt der FW_Debugger nichts. (E_NONE)
Der Fehler passiert zwischen dem Registrieren des Errorhandlers und dem Einstellen der Fehlertypen, die geloggt werden sollen.

Die Lösung
Ganz einfach: Man darf den Errorhandler erst registrieren, wenn feststeht, was wie geloggt wird. Dieser Fehler wird mir hoffentlich nie wieder passieren!

1 Star2 Stars3 Stars4 Stars5 Stars (Wurde noch nicht bewertet)
Loading...


2 Kommentare zu “Warum man nachts nicht programmieren sollte!”

  1. ja, toll, aber wieso soll man jetzt nachts nicht programmieren?

  2. Weil man da nicht fit genug ist 😛 So gehts zumindest mir

Hinterlasse einen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

»Informationen zum Artikel

Autor: Simon
Datum: 05.01.2009
Zeit: 03:42 Uhr
Kategorien: PHP
Gelesen: 5926x heute: 3x

Kommentare: RSS 2.0.
Diesen Artikel kommentieren oder einen Trackback senden.

»Meta