Konzeptfrage: abgeleitete Exception-Klasse, die automatisch loggt

**s.h.a.r.k**

Hallo zusammen,

hatte mir mal vor längerer Zeit Gedanken darüber gemacht, wie man denn am besten Exceptions loggen kann (neben anderen Meldungen). Die Grundidee war dabei, dass ich eigentlich alle Fehlermeldungen unbedingt geloggt haben will, wobei dies ja sehr stark mit Exceptions verknüpft ist.

Vorab muss ich noch sagen, dass ich einen LogController habe, der nach dem Singleton-Pattern gebaut und global verfügbar ist. Somit kann ich via LogController.Log() von überall aus eine Log-Zeile schreiben -- vorausgesetzt das loggen selbst schlägt nicht fehl. Diese Möglichkeit will ich bei meinen weiteren Betrachtungen außer Acht lassen.

Was haltet ihr davon eine Kindklasse von Exception zu erzeugen, die sich selbst loggt, d.h. wenn ich raise Exception.Create('Blub') aufrufe, wird in der Create-Methode der LogController aufgerufen, der dann die Nachricht samt Typ der Exception loggt. Dies ist natürlich der einfachste Fall, es können auch mehrere Informationen geloggt werden, da die Create-Methode überschrieben werden kann.

Nun eure Meinungen zu dieser Idee?!

**Neumann**

Die Idee finde ich gut. Man müsste wohl direkt die von Delphi mitgelieferte Exception-Klasse modifizieren; ich wüsste nicht wie eine davon abgeleitete Klasse funktionieren könnte.

Zur Zeit mache ich es so, das in jedem relevanten Except-Block ein Routine aufgerufen wird, die die e.Message, Datum und Zeit und ev. noch weiteres in die Log-Datei schreibt; z.B. den verursachenden SQL-Code bei Exceptions die mit Datenbankzugriffen zu tun haben usw.

Nicht lokal abgefangene Exceptions landen dann in einer Routine für AppException, von dort wird auch wieder in den Log geschrieben.

Gruß

Ralf

**s.h.a.r.k**

Hm, das mit den schon bestehenden Exceptions habe ich leider leicht übersehen, da ich einige eigene verwende

Somit würde des System ziemlich inkonsequent werden, wenn bei der einen Exception ein zusätzlicher Log-Aufruf nötig ist und bei der eigenen Klasse das eben automatisch passiert. Vor allem für andere Programmmierer, die das lesen, wäre es unzumutbar imho. Das Leben hätte so schön sein können *grml* Aber vielleicht fällt einem ja eine Lösung für dieses Problem ein?

**mschaefer**

Moin zusammen,

habe da doch schon mal was gesehen. Mal ganz tief in die "Wühlkiste" greif...
Uhps meine abgeleiteten TQueries zur Seite schieb... tja noch ein Parser ...
....van Genuchten Formeln... Tree mit xml export... Cobian Backup... aha ..

joop das isses doch:

http://blog.gurock.com/postings/work...tacktrace/730/

Grüße

**s.h.a.r.k**

Bin gerade mal grob drüber geflogen und schaut sehr viel versprechend aus. Mir ist gerade auch gekommen, dass man eine globale Callback-Methode definieren kann, die bei JEDER Exception aufgerufen wird, soweit ich weiß. Ich finde die Quelle allerdings nicht mehr...

-- EDIT: Hab mir da glaub scheinbar etwas geirrt. Meinte Application.OnException bzw. HandleException. Problem hierbei:

Zitat von Delphi-Hilfe:

Wird ausgelöst, wenn in der Anwendung eine unbehandelte Exception auftritt.

**RWarnecke**

Ich finde die Idee vom Grundgedanken her sehr gut. Nur sehe ich da einiges an Problemen. Ich muss selber im Quelltext aufpassen,wo könnte eine Exception auftreten. Damit könnte der Quelltext aus lauter Exception.Create oder try..except-Blöcke bestehen, was aus meiner Sicht den Quelltext ziemlich unübersichtlich macht.

Ich benutze das Tool

Eurekalog. Dieses logt mir den Fehler und wo der Fehler im Quelltext aufgetaucht ist. Das Geld für das Tool Eurekalog hat sich bis heute schon mehr als einmal bezahlt gemacht. Dort gibt es ziemlich viele Einstellungen, wie und was mit einer Exception-Meldung passieren soll.

**s.h.a.r.k**

Solche Tools werden wohl auf den selben Ideen basieren, imho, nur halt wesentlich ausgereifter sein. Der von mschaefer genannte Artikel ist hier sehr schön zu lesen. Müsste mich echt mal durch diese Tools durcharbeiten -- Problem dabei ist aber immer, dass es meist recht viele gibt und man beim Testen unendlich viel Zeit verschwenden kann. Bin aber auch gerne daran interessiert, welches Tool, denn meine Idee schon komplett implementiert hat

**alcaeus**

Moin,

ich kann leider nichts aus der Delphi-Ecke beitragen, aber in der PHP-Entwicklung hat man ja dasselbe Problem.

Prinzipiell geht es bei uns (auf Arbeit) so dass wir erstmal das

Observer pattern umgesetzt haben. Dazu haben wir eine Event-Dispatcher-Klasse, die wie folgt aufgerufen wird:
Event_Dispatcher::getInstance()->triggerEvent($eventName, $priority, $eventData)
Damit wird ein Event an die Queue $eventName geschickt - was das ist ist wirklich egal solange es als String repraesentiert werden kann (kann also auch ein Exception-Objekt sein).

Nun kann man noch ein Objekt an verschiedene Queues anhaengen:
Event_Dispatcher::getInstance()->attachHandler($eventNames, $handler)
$eventHandler muss lediglich ein bestimmtes Interface implementieren um die Message anzunehmen. Wir haben eine Logger-Klasse die die Events filtert (z.B. nach Prio) und irgendwohin schiebt (File-Log, Firebug-Log, sogar ein SMS-Interface koennte dahinter liegen)

Prinzipiell koennen wir also sowas machen:

markieren

PHP-Quellcode:

			try {

    $this->foo();

} catch (SomeException $e) {

    $this->doSomethingToFixThisStuff();

    EventHandler::getInstance()->triggerEvent('myCoolEventQueue', Zend_Log::ERR, $e->getMessage());

    EventHandler::getInstance()->triggerEvent('myCoolEventQueue', Zend_Log::DEBUG, $e);

}

Zu Deutsch schicken wir eine Exception einmal mit der Prio "Error" an die Queue, danach schicken wir die komplette Message mit Prio "Debug" an die Queue - so macht das Debuggen dann mehr Spass. So koennen wir z.B. einen File-Logger auf die Fehlermeldungen ansetzen (v.a. im Live-Betrieb), im Dev-Betrieb auch einen Firebug-Logger (der macht das Ganze schnell im Browser verfuegbar) mit Prio "Debug" auf dieselbe Queue.

Nun koennten (darauf haben wir bisher verzichtet, schliesslich ist die obige Loesung sehr umfangreich) wir auch unsere Exception-Klasse (leitet von der Standard-PHP-Exception ab) so anpassen, dass sie im Konstruktor automatisch die Message an eine bestimmte Queue (z.B. dem Klassennamen der Exception) schicken, auch wieder mit der obigen Err/Debug-Spezifizierung.
Der Grund warum wir das nicht gemacht haben ist simpel: nicht jede Exception die geworfen wird muss geloggt werden (schliesslich behandelt man sowas ja auch). Andererseits reicht es auch nicht, nur unbehandelte Exceptions zu loggen. Man will ja schliesslich auch mal eine Exception abfangen um eine "schoene" Meldung anzuzeigen und den Fehler aber trotzdem loggen. So oder so muesste man also noch zusaetzlichen Aufwand betreiben um das gewuenschte Ergebnis zu erhalten. Deshalb wird lediglich das geloggt, was die Queue macht. Einzelne Komponenten haben natuerlich ihre eigenen Queues (z.B. werden im XML-RPC-Server automatisch alle Exceptions geloggt und nicht nach aussen gegeben), aber die Anwendungen die wir entwickeln schreiben nicht automatisch alle Exceptions mit.

Greetz
alcaeus

**sx2008**

Meine Meinung: viel zu kompliziert gedacht.
Exceptions steigen ja den Aufrufstack hoch wie Bläschen in einem Sektglass.
Nur wenn sie nicht abgefangen werden, dann werden sie ganz oben auf Applikationsebene als sichtbare Fehlermeldung angezeigt.
Lediglich Exceptions, die es bis ganz nach oben schaffen sind überhaupt von Interesse um sie zu loggen.
Man braucht einfach nur einen Eventhandler für Application.OnException zu schreiben und voilà hat man die zentrale Stelle für das Loggen und für einen Stacktrace.

Mit der JCL kann man recht problemlos einen Stacktrace erzeugen.
Wenn man die Anwendung dann mit TD32-Debugger-Symbolen kompiliert oder eine Map-Datei bereitstellt, dann kann man die Exception Klasse+Message und den Stacktrace in ein Logfile schreiben.

**alcaeus**

Zitat von sx2008:

Meine Meinung: viel zu kompliziert gedacht.
Exceptions steigen ja den Aufrufstack hoch wie Bläschen in einem Sektglass.
Nur wenn sie nicht abgefangen werden, dann werden sie ganz oben auf Applikationsebene als sichtbare Fehlermeldung angezeigt.

Nicht immer. Als Beispiel: ein XML-RPC-Server versucht was in der DB zu machen und kriegt jetzt irgendeine Exception. Diese Exception muss ich abfangen, weil ich keine Infos ueber das System nach aussen dringen lassen kann (bei Web-Applikationen ist das doch ziemlich wichtig). Deshalb fange ich z.B. eine Zend_Db_Exception ab und werfe eine Zend_XmlRpc_Server_Exception, welche nur eine "Oops, something failed"-Meldung beinhaltet die fuer die Aussenwelt "safe" ist. Diese wiederum wird von der Server-Klasse abgefangen, in eine XML-RPC-Fault umgewandelt und auf den Draht gelegt. So, jetzt gibt es aber keine unbehandelte Exception. Also muss ich das Zeug irgendwie selbst loggen, es gibt aber doch was log-wuerdiges. Ganz so pauschal kann man es im Normalfall nicht behandeln.

Greetz
alcaeus