Das error_log ist definitiv kein Entwicklerwerkzeug

Genausowenig ist das error_log eines Webservers eine Mülltonne

In Firmen wo ich mal berufstätig war, herrschte ein Umgang mit Programmierfehlern vor, das war einfach nur haarsträubend. Natürlich machen Programmierer Fehler, da nehme ich mich nicht aus. Entscheidend ist jedoch, wie mit Fehler umgegangen wird, und ganz entscheident ist es, aus Fehlern zu lernen. Wer aus Fehlern lernen kann, darf auch welche machen (sage ich).

Und so wurds gemacht

Programmierer: Oh, hier könnte ein Fehler auftreten, da notieren wir mal eine Warnmeldung. Oops, wars das?

Ja, das wars auch schon, notiere warn('was auch immer hier passiert ist...') und das wars. Von all den Kollegen, die so programmiert haben, hat nicht einer mal wieder in das error_log geschaut. Das ist nicht nur verantwortungslos, sondern auch in höchstem Maße unkollegial. So nach dem Motto, die Anderen werdens schon richten, Hannemann, geh Du voran. Bis eines Tages der Chef mal auf die Idee kam, sich das error_log anzuschauen. Denn das war mittlerweile größer als das access_log, ein Request, drei Fehler.

Programmierer: Lass ein tail -f laufen, so kannst Du mit Deinem Code ausgegebene Warnmeldungen gleich sehen .

Ich: Schön wärs ja, aber sobald ich tail -f anweise, kommen haufenweise Meldungen so schnell, so schnell kann ich gar nicht gucken.

Die hier zitierten Dialoge machen das ganze Ausmaß des Dilemmas deutlich. Mit Sicherheit ist das keine empfehlenswerte Arbeitsweise.

Und so machen wir das in Zukunft besser

Ganz einfach: Raise Error, erheben wir sämtliche Fehlermeldungen, einschließlich Warnmeldungen, in den Status einer Exception, fangen jede Exception auf und geben die dazugehörige Meldung jeder Exception sofort im Browser aus! Das schafft eine optimale Entwicklungsumgebung, auch wenn das auf den ersten Blick nicht so einleuchtend ist. Was jedoch sofort einleuchtet ist, dass jeder Entwickler auch einmal selbst eine gezielte Exception werfen kann, etwa um sich eine bestimmte Datenstruktur im Browser ausgeben zu lassen.

Und selbstverständlich werden wir uns überlegen müssen, worin der Unterschied zwischen vorhersehbaren und unvorhersehbaren Fehlern bestehen könnte. Wesentlich ist, dass unvorhersehbare Fehler eines Eskalationsprozesses bedürfen, beispielsweise, wenn ein Datenbankserver nicht mehr erreichbar ist. In solchen und ähnlichen Fällen nützt uns das error_log nämlich null Komma nix und schon gar nix, wenn wir da alle Jahre wieder mal da reinschauen. Hierzugehörige Stichworte lauten Prevention und proaktives Management.

Am Ende bleibt das error_log eine leere Datei...und ist sowohl für Programmierer als auch für den Technischen Leiter (CTO) uninteressant.

CGI: Fatals to Browser

Notieren Sie in der main oder an einer anderen geeigneten Stelle einen BEGIN-Block wie folgt:

BEGIN{
    $SIG{__DIE__} = sub{
        local $, = "\n";
        print 
          "Content-Type: text/plain; Charset=UTF-8\n\n", 
          "Fehler-Report", @_;
    };
    $SIG{__WARN__} = $SIG{__DIE__}; # ggf.
}

Dieser Block sorgt dafür, daß alle Fehlermeldungen im Browser landen, so werden sie bereits beim Entwickeln bemerkt.

Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. sos@rolfrost.de.