SQL-Injektionen, CrossSite Scripting, Affenformular u. Usability

[dedlfix]

echo $begrüßung;

Ich kenn es nur von Perl und da ist die() ein probates Mittel und Fehler mitzuteilen und diese lassen sich mittles $SIG{__DIE__} = sub {} auch abfangen. Genau wie warn. Damit ist eine sehr vielschichtige Fehlerdiagnose möglich, die sich sogar im produktiv Einsatz benutzen läßt

Das sieht mir aber eher nur nach einem Diagnosewerzeug statt nach einer geplanten Reaktion auf vorhersehbare Fehler aus. (Dass eine Datenbank mal nicht erreichbar ist, ist beispielsweise ein vorhersehbarer Fehler.) Ziel sollte immer sein, dass ein Script an seinem Ende ankommt. Dabei darf es gelegentlich Umwege nehmen, auch wenn diese die Hauptattraktion umfahren. Das ist immer noch besser als mit Motorschaden auf der Strecke liegenzubleiben.

ich lass mir z.b. die die() Meldungen als e-mail schicken

Man kann sich unter PHP eine eigene ErrorHandler-Funktion (für alle nicht-fatalen Fehler) schreiben und mit set_error_handler() aktivieren. In diesem ErrorHandler kann man sich beispielsweise eine E-Mail schicken lassen. Diese Funktion wird bei jedem Auftreten eines PHP-Fehlers aufgerufen. Der Programmablauf wird dabei aber nicht abgebrochen. Nach Ende der ErrorHandler-Funktion geht es weiter im Kontext des Hauptscripts.

MySQL-Fehler sind ja erstmal keine PHP-Fehler, weswegen bei einem solchen der ErrorHandler zunächst nicht anspringt - erst bei Folgefehlern, doch dann fehlt einem der eigentliche Fehlerauslöser inklusive dessen Wortlaut. Nun könnte man annehmen, das die() durch ein trigger_error() auszutauschen. Dann bekommt man zwar einen Aufruf des ErrorHandlers inklusive eine "Maildung" nach Hause, läuft dann aber im Hauptscript fröhlich in Folgefehler.

Der eigene ErrorHandler ist also auch kein Ersatz für eine Fehlerbehandlung. Er kann lediglich ein zusätzliches Hilfsmittel sein, um auf Probleme aufmerksam zu machen, die sonst nur die Anwender zu Gesicht bekommen.

echo "$verabschiedung $name";