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

Delphi-Quellcode:

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

Delphi-Quellcode:

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 :wall: 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:

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:

PHP-Quellcode:

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:

PHP-Quellcode:

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:

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

[Phoenix]

Prinzipiell steht dem nichts im Wege.
In einem größeren Projekt (allerdings in C#) haben wir auch eine 'AuditedException' die sich selber loggt.

Problematisch ist allerhöchstens, dass gewisse Fälle, in denen in einem try-catch block eben diese Exception sauber behandelt und entsprechend (richtig) korrekt fortgeführt wird, diese Exception dennoch geloggt wird, obwohl kein 'echter' Fehlerfall eingetreten ist.

[alcaeus]

Moin Sebastian,

wie macht ihr das? Werft ihr dann extra eine AuditedException? Wir haben es so dass alle Packages ihre eigenen Exceptions haben: z.B. nutzt Zend_XmlRpc_Server die Exception Zend_XmlRpc_Exception. In so einem Fall braeuchte man ja eine Zend_XmlRpc_Exception und eine Zend_XmlRpc_AuditedException, welche eben von Zend_AuditedException ableiten wuerde anstatt von Zend_Exception. Ist das bei euch auch so oder wie kann ich mir das vorstellen?

Zum Loggen: in PHP ist es so dass die Objekte irgendwann zerstoert werden. Die Exception koennte ja auch als unhandled markiert werden, im Catch-Block markiert man sie anschliessend mit ->handle() als handled. Im Destruktor schiebt man dann die Exception (siehe obige Erklaerung) noch auf eine Queue raus, sofern sie nicht gehandled wurde. Man muss dann zwar im Catch-Block noch ein $exception->handle() schreiben, aber das koennte das Problem ja beheben, oder?

Greetz
alcaeus