AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Optimales Logging: Assert-basiert oder NULL-Logger: Ja oder besser nicht ?

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

Ein Thema von Rollo62 · begonnen am 17. Dez 2019 · letzter Beitrag vom 19. Dez 2019
Antwort Antwort
Seite 2 von 2     12
Medium

Registriert seit: 23. Jan 2008
3.682 Beiträge
 
Delphi 2007 Enterprise
 
#11

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

  Alt 17. Dez 2019, 22:51
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.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
4.016 Beiträge
 
Delphi 12 Athens
 
#12

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

  Alt 18. Dez 2019, 09:27
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.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.013 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#13

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

  Alt 18. Dez 2019, 10:42
@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...
Bitte wenigstens richtig lesen, ich schrieb SmartInspect - das ist funktionsgleich wie CodeSite.
Es ging aber darum, dass man nix über Defines raus nimmt sondern einfach den Log Aufruf im Code hat, in diesem aber nichts weiter tut, wenn der Logger nicht aktiviert ist.
Sollte der Logaufruf schon potenziell zu teuer (messen, nicht raten!) sein, dann kann man einen Ansatz nutzen, wie in Phillip in #10 beschrieb.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
4.016 Beiträge
 
Delphi 12 Athens
 
#14

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

  Alt 18. Dez 2019, 11:01
Ja sorry, typo beim Lesen
Trotzdem SmartInspect scheint auch nicht für Mobile geeignet zu sein.
Wenn ich erst tief in Google nach solchen Features suchen muss, ohne Ergebnis, scheint es bei Beiden nicht drin zu sein.

Die ViewerOberflächen scheinen ja Einiges zu können, aber da muss man sich erstmal reinarbeiten.
Vielleicht bleibe ich erstmal bei Grijjy/Logcat, damit kenne ich mich besser aus,
aber ich werde die Beiden mal bei Gelegenheit genauer anschauen was deren Unterschiede ausmacht.

Ja, ich checke gerade einen Ansatz mit if, wie ihn Phillip beschrieben hat,
aber zusammen mit dem Interface/Inline Ansatz.
Mein Ziel wäre es die Gruppen für verschiedene Module möglichst zenrral zu steuern, und es könnte in diese Richtung gehen.
Vielleicht könnten die Gruppen sich selbst registieren, in der initialization section.
Auch das Logging komplett abschalten, über Defines in einer Log.pas, könnte ich dann immer noch.
  Mit Zitat antworten Zitat
Medium

Registriert seit: 23. Jan 2008
3.682 Beiträge
 
Delphi 2007 Enterprise
 
#15

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

  Alt 19. Dez 2019, 09:30
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.
Mit mobile Entwicklung habe ich nichts am Hut. Worum es mir insbesondere geht, ist eine Möglichkeit beliebige Strings threadsicher an den UI Thread zu übergeben. Bisher mache ich das über manuell allozierte Char-Arrays und den Pointer dazu im lParam der Message. Dann muss der Empfänger freigeben. Heißt auch, dass ich immer dran denken muss in jede Fensterklasse (HWND) an die ich Logs schicke einen entsprechenden Handler implementieren muss. Sonst Speicherlecks. Und modern oder elegant ist das auch nicht.
Verschiedene Messages für verschiedene Meldungen sind noch schlimmer, da dann jede einen eigenen Handler braucht. Man spart sich dann zwar das Char/String Gehampel da man einfach die Texte im Handler anlegt (oder besser ressourcestrings nutzt), aber das ist für jede neue Log-Art ein ziemlicher Aufriss, und die Fensterklasse besteht nachher zu 50% aus Log-Handlern. Nichts um mal ad hoc einen Bug zu finden.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:14 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz