Konzeptfrage: abgeleitete Exception-Klasse, die automatisch loggt

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

Zitat von sx2008 (Beitrag 1067554)

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

[shmia]

@alcaeus: Aber auch in diesem Fall ist die Behandlung und das Loggen relativ geradeaus.
Beispiel: bei einem Seriendruck können Fehler auftreten, der Seriendruck soll aber weiterlaufen und die Fehlermeldungen in einem Memo angezeigt werden:

Delphi-Quellcode:

while not SeriendruckFertig do
begin
  try
    Seriendruck;
  except
    on E:Exception do
    begin
      Logger.LogException(E);
      MemoError.lines.Add('Fehler: '+ E.Message);
    end;
  end;
end;

Leider unterstützt Delphi keine Nested Exceptions, dann könnte man die orginale Exception in einer neuen Exception mit Logging-Funktionalität verpacken.
So aber würde ich ganz "konservativ" das Loggen wie im Beispiel oben vornehmen und natürlich an der zentralen Stelle Application.OnException.

[Deep-Sea]

Ich habe den Thread nicht weiter durchgelesen und kann auch nicht viel schreiben, da ich weg muss. Falls ich also doch das Thema verfehlen sollte oder es schon gesagt wurde: Sry! :-D

Schau dir die globale Variable RaiseExceptObjProc der Unit System an. Diese zeigt standardmäßig auf Die Funktion RaiseExceptObject der Unit SysUtils. Schreibe deine eigene Funktion dafür, weise sie zu und ruf die alte Methode ebenfalls auf.
Ob das alles so schön und zuverlässig geht weiß ich nicht, hab's nie getestet. Aber einen Versuch ist es wohl wert.

Der Konstruktor einer Exception ist ungeeignet zum loggen. Denn nur weil eine Exception, die ja ein normales Delphi-Objekt ist, erzeugt wird, muss sie noch lange nicht ausgeworfen werden. In dem Fall hilft die virtuelle Methode RaisingException der Klasse Exception.

Für einen Stacktrace kann man die Unit JclDebug der JEDIs nutzen. Nutze ich selbst für meine abgeleiteten Exceptions (mit "nested" Funktionalität) und Fehlerberichte, klappt soweit ganz gut.

PS: Das loggen von Fehlern steht auch schon lange auf meiner Todo-Liste :roll:


Schönes Wochenende euch allen :thumb:

Edit:
So, jetzt habe ich Zeit. Ich wollte noch erwähnen, dass man Application.OnException und anderen Events von Application NICHTS zuweisen sollte! Dafür ist die Komponente TApplicationEvents (oder irgendwie so heißt sie) da.

[Deep-Sea]

*thread rauskram*

Hat denn nun mal jemand meinen Vorschlag mit RaiseExceptObjProc getestet?
Ich würde nämlich jetzt auch mal gerne mit einem Exception-Log anfangen und da wären evtl. Erfahrungen doch ganz nützlich :-D