robust-co.de

– Robustes Loggen

Robustes Loggen

01.05.2014

Damit ein robustes Programm in der Praxis verwendet werden kann, muss es nicht nur mit jeder Situation ohne Absturz umgehen können. Es muss vielmehr auch signaliseren, wenn solch eine Situation eingetreten ist. Andernfalls ist es kaum möglich, Fehler zu finden.

Was soll geloggt werden?

Ich bin der Meinung, dass so wenig wie möglich geloggt werden soll. Ansonsten ertrinkt man in einer Flut von Meldungen und erkennt die Probleme nicht.

Es gibt Fehler, die so klar sind, dass sie nicht protokolliert werden müssen. Nehmen wir als Beispiel eine Java-Methode, die einen Namen komplett in Großbuchstaben wandelt:

String toTitle(String name) {
    return name != null ? name.toUpperCase() : null;
}

Die Funktion kann nicht ausgeführt werden, wenn sie mit null aufgerufen wird. In diesem Fall wird auch eine null zurück geliefert. Sollte dies geloggt werden?

Meiner Meinung nach: Ja. Zu einem großen Aber komme ich weiter unten. Die Methode kann nicht richtig funktionieren. Das sollten wir mitteilen. Und ebenso sollten wir mitteilen, warum.

String toTitle(String name) {
    if (name == null) { System.err.println("name is null"); return null; }
    return name.toUpperCase();
}

Wenn man alle Methoden nur mit korrekten Parametern aufruft, wird nichts geloggt. Das sollte unser Ziel sein.

Doppelten Code vermeiden

Das führt aber zu viel Code. Nehmen wir einen JSON-Parser. Beim Parsen eines empfangenen Strings können Fehler auftreten, die geloggt werden. Um dieses Logging zu verhindern, muss der String validiert werden, bevor er geparst wird. Dazu ist ein Parser notwendig. Die Katze beißt sich in den eigenen Schwanz.

Ich verwende daher gerne das Konzept der LogHandler: Der Logger sendet die Nachrichten an alle registrierten Handler. Für den JSON-Parser können wir vor dem Parsen alle Logger ausblenden. Nach dem Parsen werden die alten Handler wieder aktiviert. Wenn ein Fehler aufgetreten ist, kann nun eine Log-Meldung ausgegeben werden, dass das JSON nicht valide ist.

Wichtig ist, dass nicht der JSON-Parser entscheidet, ob geloggt werden soll, oder nicht. Der aufrufende Prozess kann entscheiden, wo die Nachrichten abgelegt werden. Es liegt allerdings auch in der Verantwortung des Prozesses Auswirkungen selber zu loggen, wenn er Meldungen ausblendet.

In späteren Beiträgen möchte ich dieses Konzept mit unterschiedlichen Sprachen und Log-Systemen vorstellen.


Kommentare

Möchten Sie einen Beitrag korrigieren, ergänzen oder kommentieren? Senden Sie mir eine E-Mail an timm@robust-co.de. Interessante Beiträge veröffentliche ich gerne auf dieser Seite.