Optimales Logging: Assert-basiert oder NULL-Logger: Ja oder besser nicht ?

[Rollo62]

Ja dankesehr, Grijjy kenne ich auch.
Der ist schon nahe an Perfekt, weil es eine ganze Infrastruktur bietet.
Ich denke aber das alle Logger die ich bis jetzt gesehen habe im Prinzip ähnlich funktionieren.

Was ich meine ist, das Senden einer Message:
XyzLog.Send('Sample Info Message', TgoLogLevel.Info); wir mehr oder weniger immer so gemacht.

Ich möchte aber genau diesen Code mal aktive, und mal inaktiv schalten können.

Delphi-Quellcode:

Uses  XyzLog;

// Globales abschalten möglich, z.B. über .inc Datei, wenn _X_LOG undefiniert ist
// Globales Abschalten bei RELEASE
{$IF DEFINED( _X_LOG) and DEFINED(DEBUG) }  
{$UNDEF  _X_LOG}  // remove the global, and handle the local scope
{$DEFINE _X_LOG}  // Lokales, Unit-scope Abschalten hier möglich
{$ENDIF}


// Das ginge z.B. so 
// Spezielles Abschalten ist hier möglich
{$IFDEF _X_LOG} XyzLog.Send('Sample Info Message', TgoLogLevel.Info);  {$ENDIF}

Das würde wohl funktinieren, ist aber rein optisch nicht so mein Favorit
Ich suche da eigentlich nach einer eleganteren Version ohne zu viele ifdefs (falls es die gibt)

[TiGü]

Und wenn du die IFDEFS innerhalb der Send/Log-Methoden machst (ggf. den Logger der Wahl einfach wrappen)?

[Rollo62]

Ja die LogFunktionen liegen in einer anderen Unit.
Da kann ich globale Features gruppieren, etc., muss aber immer mit .inc Dateien hantieren.
Schöner fände ich das im Kopf einer Unit.

Was dann aber trotzdem passiert, ist das Aufrufen evtl. leerer Funtionen,
den Funktion-Call würde ich natürlich auch gerne im RELEASE wegbekommen.

Man könnte evtl. auch was mit Mocks machen, aber ich meine die sind dafür auch nicht optimal.

Es geht z.B. um Folgende Situation:
Ich muss ein Problem debuggen, und baue dafür an zig Stellen in einer/mehreren Units Logs ein.
Wenn das läuft müsste ich
1. entweder alle Logs wieder rausbauen
2. oder die Logs einfach "ausschalten" (und möglichst NUR diese)

Ich möchte halt 2tes Erreichen, auch weil ich die Logs für spätere Tests noch drinbehalten möchte.

Mit Asserts wäre das z.B. möglich, denn man kann im Kopf einer Unit Assertions ein/ausschalten
$ASSERTIONS ON/OFF und damit wäre der Aufruf der Asserts weg (keine leere Funktion wird benötigt)

[dummzeuch]

Ich nehme an, Du meinst bei der Assertion-basierten Lösung sowas wie:

https://stackoverflow.com/a/16459891/49925

Assert(False, 'Dies ist eine Logmeldung');
Ich habe das mal ausprobiert und bin da nicht so der Fan:

Vorteil Assertion:
* Man kann das Logging recht einfach komplett ausschalten
* Man kommt einfach an die Zeilennummer der Assertion, in der die Log-Message geschrieben wird.

Nachteil Assertion:
* Wer es nicht kennt, den verwirrt diese Verwendung von Assert.
* Assertions sind ziemlich CPU-Intensiv, d.h bei eingeschaltetem Logging ändert sich das Zeitverhalten stark.
* Man kann Assertions nicht mehr anderweitig verwenden.

Persönlich bevorzuge ich die NULL-Logger-Lösung. Es ist einfach sauberer.

[Uwe Raabe]

Zitat von Rollo62:

Was dann aber trotzdem passiert, ist das Aufrufen evtl. leerer Funtionen,
den Funktion-Call würde ich natürlich auch gerne im RELEASE wegbekommen.

Ich glaube, das hatten wir schon mal irgendwo an anderer Stelle (eventuell auch bei DP-EN oder SO). Wenn du die Methoden inline deklarierst, sollte gar kein Call mehr gemacht werden. In diesem Beispiel erzeugen die T.Init und T.Log Aufrufe keinen Code, wenn in uLogging nicht Log definiert ist.

Delphi-Quellcode:

procedure Main;
var
  T: TLog;
begin
  T.Init('TLogConsole');
  T.Log('Hallo Welt');
  Writeln('Wie geht''s?');
  Readln;
end;

Delphi-Quellcode:

unit uLogging;

interface

{.$DEFINE Log}

type
  ILog = interface
  ['{76BA1F8A-D171-4817-BB3D-337295B03CE0}']
    procedure Log(AText: string);
  end;

  TLog = record
  private
    {$IFDEF Log}
    FLog: ILog;
    {$ENDIF}
  public
    procedure Init(const AName: string); inline;
    procedure Log(AText: string); inline;
  end;

implementation

type
  TLogConsole = class(TInterfacedObject, ILog)
  public
    procedure Log(AText: string);
  end;

procedure TLogConsole.Log(AText: string);
begin
  Writeln(AText);
end;

procedure TLog.Init(const AName: string);
begin
  {$IFDEF Log}
  // der Einfachheit halber
  FLog := TLogConsole.Create;
  {$ENDIF}
end;

procedure TLog.Log(AText: string);
begin
  {$IFDEF Log}
  if FLog <> nil then begin
    FLog.Log(AText);
  end;
  {$ENDIF}
end;

end.

[freimatz]

Zitat von Rollo62:

Das würde wohl funktinieren, ist aber rein optisch nicht so mein Favorit
Ich suche da eigentlich nach einer eleganteren Version ohne zu viele ifdefs (falls es die gibt)

Und wenn Du die ifdef im aufgerufenen logging code machst?
Ich meine wenn Du dort per ifdef den logging code ausklammerst und die Methode noch als inline deklarierst - würde der Compiler die dann nicht wegoptimieren?

[Stevie]

Ich persönlich bin ja Fan von dem Ansatz, den CodeSite, SmartInspect o.ä. verfolgen. Da bleibt der Aufruf grundsätzlich auch in nem Release Build drin, ist aber so geschrieben, dass er wenigstmöglich weh tut, wenn das Logging ausgeschaltet ist. Da hat den Vorteil (tun wir bei unserem Produkt täglich), dass man dem Kunden das mal kurz anschalten lassen kann, er schickt die Logdateien und der Support und/oder Entwicklung kann das auswerten.

Asserts gehören mMn ebenso wie Range und Overflow Checking im Release ausgeschaltet.

Eine wirklich gute Lösung für Logging hat man mMn sowieso nur, wenn die Sprache nativ AOP kann oder so Dinge wie PostSharp möglich sind.

[philipp.hofmann]

Ich bin auch immer für ein zur Laufzeit aktivierbares Logging. Erleichert die Arbeit beim Kunden. Um es möglichst ressourcen-schonend umzusetzen ist dann wichtig, dass man zumindest für den Level INFO und DEBUG zuerst per boolean prüft, ob geloggt werden soll, bevor der zu loggende String angelegt wird. Generell nutze ich TMSLogging und je nach OS (z.B. Android) zusätzlich Log.d(''), damit es in den Prelaunch-Reports auftaucht.

Code:

if (myLog.isInfoEnabled()) then
begin
  {$IFDEF ANDROID}
     Log.d('INFO: XXXXXXX');
  {$ENDIF}
  myLog.info('XXXXXXXX');
end;

[Medium]

Interessanter Thread! Was ich mich bei all den Lösungen hier gefragt habe ist: Wie schaut es mit Multi-Threading aus? Gerade dabei würde ich mir oft eine einfache Möglichkeit des Loggings wünschen, ohne kompliziert erst Messages zu definieren, HWNDs überall hin durchzureichen, an gewünschten Stellen solche Events auszulösen und mit l/wParam-Pointer-Missbrauchten handgestreichelten Strings zu hantieren. Möglichst ohne allzuviel Aufwand eine solche Lösung in bestehende Projekte zu bringen, die nicht spezifisch darauf hin erstellt wurden.

[Rollo62]

Dankesehr für die Vorschläge und Kommentare.

@dummzeuch
Ja, genau das meine ich (Assert- oder Assertion-basiert, mir fehlt da der richtige Bezeichner).
Das mit Vor- Nachteil sehe ich ähnlich.
Es könnte da auch noch den Nachteil geben mit vorhandenen Asserts (in Library oder 3rd Party), das könnte dann womöglich mal in die Hose gehen.
Ich bin ja Mental auch eher bei einem NULL-Logger.

@freimatz
@Uwe Raabe
Ja das hatten wir schonmal so ähnlich, aber nicht als komplette Infrastruktur.
Inline und Interfaces können helfen, könnte eine lokale Gruppierung dann so aussehen ?

Delphi-Quellcode:

// Das könnte global in einem Log.Types Unit liegen, zur zenralen Steuerung, oder 
// dort auch  per ifdef's gesteuert
const
    CLog_Group_1 = 1;  // per 0/1 individuell abschaltbar
    CLog_Group_2 = 0;  // per 0/1 individuell abschaltbar
    CLog_Group_3 = 1;  // per 0/1 individuell abschaltbar

procedure Main;
var
  T: TLog;
begin
  T.Init('TLogConsole');
  // Hierbei kann zwar Log weggeschalted werden ,aber nicht die Groups zentral verwaltet werden
  T.Log(CLog_Group_1, 'Hallo Welt');  
  T.Log(CLog_Group_2, 'Hallo Welt');
  T.Log(CLog_Group_3, 'Hallo Welt');

  // So könnte es gehen, wenn die Groups im Log z.B. als class var verwaltet werden.
  T.LogGroup_Enable(CGroup1, CLog_Group_1);
  T.LogGroup_Enable(CGroup2, CLog_Group_2);
  T.LogGroup_Enable(CGroup3, CLog_Group_3);
  //
  T.LogGroup_1('Hallo Welt');  
  T.LogGroup_2('Hallo Welt');
  T.LogGroup_3('Hallo Welt');
  // Nachteil: TLog müsste eine Menge über die Module wissen, damit könnte ich aber womöglich Leben
end; 

Könnte interessant sein, muss ich mal checken.

@Stevie
Mit denen habe ich mich nur theoretisch beschäftigt, aber ich denke
CodeSite ist nicht FMX/Mobile: das wäre ein NoGo für mich.
Leider finde ich sehr wenig konkrete Daten darüber.

SmartBear dito

Zitat:

"TestComplete does not support applications built by using cross-platform GUI frameworks that render the application controls as graphic (for example, Embarcadero FireMonkey)."

Oder meintest Du etwas anderes als TestComplete für das einfach Logging ?

Wie genau machen die das denn im Code, ich vermute mal das es so eine Art "Sprungmarken" dort gibt, als Pointer zu den eigentlichen LogFunktionen.
Sorry, ich habe keines der Beiden installiert.
Oder könnte das etwa der gleiche Ansatz mit Interfaces sein, und je nach Anforderung auf NullInterfaces zeigen lassen ?

@Phillip Hoffman
Ja das wäre auch eine schöne Option, würde ich auch gerne unter Gruppierung sehen.
Ich denke dabei wird dan immer ExtraCode in den Units bleiben, aber gut für PreRelease Tests.
Ich mache sowas teilweise mit zuschaltbarem Logging, in einem speziellen Debug-Modus meiner Apps, die dann lokale Logs anzeigen können.
Damit kann ich sogar per Hotline mit den Kunden Einzelfälle besser debuggen.

@Medium
Im Prinzip ist MultiTread kein Problem (höchstens der zusätzliche Overhead und Performaceverlust).
Nur die Anzeige der Logs muss im UI-Thread, oder noch besser extern erfolgen.
Schau dir mal ein Android Logcat von einem Phone an, das sended andauernd zig Logs, auch wenn im Frontend gar nichts passiert, da kommt Einiges aus Threads.