nicht angemeldet
echo $begrüßung;
Aber wie sag ich der "logging"-Funktion
DU BEFINDEST DICH: Datei, Klasse, Funktion, Zeile und der Fehler ist ein PHP oder MySQL Fehler UND den Fehler lautet: XXX
Im Kapitel Error Handling and Logging gibt es unter anderem eine Funktion debug_backtrace(). Die zeigt dir die gesamte Aufrufreihenfolge bis zum aktuellen Zeitpunkt inklusive der Parameterwerte von Funktionen. Den aktuellen Inhalt der Variablen im derzeitigen Kontext bekommt man mit einem get_defined_vars(). Und wenn track_errors eingeschaltet ist, findet man den Text des Fehlers in der Variable $php_errormsg. get_defined_vars() und $php_errormsg muss man nur dann selbst angeben, wenn der Fehler händisch geloggt wird. Wenn du einen Error-Handler schreibst, bekommt der bis auf den Debug-Trace automatisch alles übergeben. Allerdings springt dieser auch bei mit @ unterdrückten Fehlern an. Diesen Zustand kann man durch Abfragen des Rückgabewertes von error_reporting() ermitteln, denn der ist dan 0.
Auf den @ kann man nicht generell verzichten. Gerade wenn man in einigen Fällen so arbeitet, dass man Fehler erwartet und dafür die Meldung nicht braucht muss man sie mit @ ausschalten. Das error_reporting generell auf 0 zu setzen bringt nichts, weil man dann im Error-Handler nicht mehr gewollte und ungewollte Fehler voneinander unterscheiden kann. Wann so ein @-Fall eintritt merkt mann beim Entwickeln und Testen, denn man testet ja auch ausgiebig die Fehlerfälle (wenn man eine robuste Anwendung schreiben will).
Ein Beispiel dazu ist getimagesize(). Wenn mich der Unterschied zwischen "ist zwar vorhanden aber keine Bilddatei" und "Datei existiert nicht oder ist nicht lesbar" nicht interessiert, dann muss ich auch nicht aufwendig vorher mit file_exists() oder is_readable() darauf testen. Es reicht dann, einfach getimagesize() aufzurufen und false als Rückgabewert zu erwarten. Dummerweise (in meinem Fall) gibt es dabei eine Warnung, die man weder sehen noch loggen will, also: @. Generell sollte man den @ nicht überstrapazieren sondern nur nach ausgiebigen Tests und wohl überlegt einsetzen.
Die Konfiguration von error_reporting sollte man im Labor und in der Produktivumgebung auf E_ALL stehen haben. Für die Produktivumgebung ist ein Logging erforderlich, sonst ist das E_ALL sinnlos. display_errors sollte man nur im Labor eingeschaltet haben oder aber seinen Error-Handler so programmiert haben, dass er die Fehler anzeigt, damit man sofort eine Rückmeldung bekommt, dass da noch eine Baustelle offen ist.
Und zu guter Letzt sei noch die Funktion trigger_error() erwähnt, mit der man gezielt Fehlermeldungen erzeugen kann, die man dann im eigenen Error-Handler loggen kann. Der Vorteil dabei ist, dass man wie bei "richtigen" Fehlern den aktuellen Kontext mit übergeben bekommt.
echo "$verabschiedung $name";