Programmablauf Protokollieren

[martin_]

Hallo,
bin auf der Suche nach einer Möglichkeit den Ablauf meines Programms zu Protokollieren. Dh. bestimmte Zugriffe auf Objekte, Rückgabewerte und Zustände die kritisch sind.
Gibt es hierfür eine fertige Lösung die einfach zu integrieren ist?
Danke

[stahli]

Welche Delphi-Version hast Du denn?

Im XE sind CodeSite und AQTime enthalten. Damit kann man komfortabel Informationen ausgeben und Zeitanalysen durchführen.

Als Billiglösung kannst Du Infos in ein Memo oder Textdatei schreiben.
Ich könnte bei Bedarf eine alte Unit raussuchen, in der ich so etwas in Funktionen verpackt habe.

Ganz einfach ist auch folgende temporäre Lösung für kurze Infos:
Application.MainForm.Caption := 'Kurzinfo' + ' ' + Application.MainForm.Caption;

Und zur Designzeit natürlich auch OutputDebugString...

[Aphton]

Callbacks? Mit Compilerdirektiven eingesetztes Logging?

[CCRDude]

Ich hab ne Weile SmartInspect probiert. Wenn Geld keine Rolle spielt(TM) ist das eine schnell zu implementierende und sehr komfortable Möglichkeit.

Letztendlich habe ich das aber erst in eigener Unit gekapselt (300 $ sind ja kein Pappenstiel), und dann ersetzt durch diverse eigene Möglichkeiten (Logfile, OutputDebugString, AllocConsole + WriteLn, etc.). Gerade OutputDebugString ist für die Arbeit im Debugger schön einfach.

Wichtig: wie Aphton schon schrieb, am besten mit Direktiven, um im kompilierten Release keine Laufzeiteinbußen dadurch zu haben.

[generic]

wie wäre es mit log4delphi?

http://log4delphi.sourceforge.net/index.html

Das gibt es auch für andere Sprachen:

log4net
log4java
log4php

[Stevie]

Zitat von Aphton:

Mit Compilerdirektiven eingesetztes Logging?

Zitat von CCRDude:

Wichtig: wie Aphton schon schrieb, am besten mit Direktiven, um im kompilierten Release keine Laufzeiteinbußen dadurch zu haben.

Absolut falsch. Auch in einem Release build sollte Logging enthalten sein. Es sollte nur möglicherweise standardmäßig deaktiviert sein. Aber wenn irgendwo im laufenden Betrieb ein Fehler entsteht, kann man wohl in den seltensten Fällen mal ebend nen Debug Build an den Kunden geben um irgendwas zu protokollieren.

[CCRDude]

Zitat von Stevie:

Absolut falsch.

Absolut? Das ist aber eine ziemlich absolute Meinung.

Ein möglichst umfassendes Logging klappt zum Beispiel nur mit Kompilaten, die Debug-Informationen beinhalten. Dann kompiliert man ein Logging-Build natürlich auch nicht mit Runtime Packages. Und schon lieferst Du auf einmal die fünffache Datenmenge aus. Das kannst Du vielleicht für Individualsoftware machen, aber nicht für die breite Masse.

Außerdem steht da wieder die Performance-Frage. Wenn Du bis ins feinste Detail präpariest, also jeder einzelnen Methode/Funktion/Prozedur Enter- und Leave-Aufrufe hinzufügst, ist der Performance-Einbruch dadurch nicht mehr hinnehmbar, sobald es um irgend welche rechenintensiven Geschichten geht. Selbst wenn das logging komplett inline sein sollte, bedeutet "standardmäßig deaktiviert" immer noch etliche Abfragen.

Nichts gegen eine ordentliche Fehlerbehandlung im Public Release, die ist im Gegenteil extrem wichtig, aber das komplette Logging gehört da - mMn nach - auf keinen Fall rein. Zumindest nicht so "absolut", wie Du es darstellt.

[mquadrat]

Ohne Logfiles ist man immer darauf angewiesen einen Fehler reproduzieren zu können. Das funktioniert aber eigentlich nur, wenn die einzigen Beteiligten der Nutzer und Software sind. In dem Fall braucht man eigentlich nur Abweichungen von der Norm zu protokollieren.

Wer schon mal ein Projekt in der Automatisierungstechnik gehabt hat, weiß das Reproduzieren da schwierig bis unmöglich ist. Besonders wenn sämtliche Komponenten neu sind, schiebt sich da jeder gerne gegenseitig die Schuld zu. Hat man da ein Logfile, das sauber protokolliert, dass für die angelegten Eingangssignale / Barcodes / Config-Dateien / Serverrückgaben die richtigen Ausgangssignale gesetzt wurden, kann man sich zurücklehnen. Ansonsten ist erst mal immer die Software schuld.

[Aphton]

Zitat von CCRDude:

Zitat von Stevie:

Absolut falsch.

Absolut? Das ist aber eine ziemlich absolute Meinung.

Ein möglichst umfassendes Logging klappt zum Beispiel nur mit Kompilaten, die Debug-Informationen beinhalten. Dann kompiliert man ein Logging-Build natürlich auch nicht mit Runtime Packages. Und schon lieferst Du auf einmal die fünffache Datenmenge aus. Das kannst Du vielleicht für Individualsoftware machen, aber nicht für die breite Masse.

Außerdem steht da wieder die Performance-Frage. Wenn Du bis ins feinste Detail präpariest, also jeder einzelnen Methode/Funktion/Prozedur Enter- und Leave-Aufrufe hinzufügst, ist der Performance-Einbruch dadurch nicht mehr hinnehmbar, sobald es um irgend welche rechenintensiven Geschichten geht. Selbst wenn das logging komplett inline sein sollte, bedeutet "standardmäßig deaktiviert" immer noch etliche Abfragen.

Nichts gegen eine ordentliche Fehlerbehandlung im Public Release, die ist im Gegenteil extrem wichtig, aber das komplette Logging gehört da - mMn nach - auf keinen Fall rein. Zumindest nicht so "absolut", wie Du es darstellt.

Bin da absolut deiner Meinung

[jaenicke]

Zitat von CCRDude:

Ein möglichst umfassendes Logging klappt zum Beispiel nur mit Kompilaten, die Debug-Informationen beinhalten.

Warum? Es reicht doch, wenn ggf. die Adresse geloggt werden, sofern zu jeder ausgelieferten Version auch die Map-Files und externen Debuginformationen existieren.

Zitat von CCRDude:

Außerdem steht da wieder die Performance-Frage. [...] Selbst wenn das logging komplett inline sein sollte, bedeutet "standardmäßig deaktiviert" immer noch etliche Abfragen.

Naja, so viel ist das auch wieder nicht.

Delphi-Quellcode:

if Assigned(MyLogFunction) then
...

Das sollte nicht viele Zyklen brauchen.

Es ist eher die Frage was geloggt wird. Und welche Informationen davon für den laufenden Betrieb relevant sind, wenn es zu einem Fehler kommt. Das Loggen an sich sollte in nahezu allen Fällen von der Rechnerzeit her kaum relevant sein, wenn man es auf diese Weise einbaut und deaktiviert hat.