Diskussion zum Artikel "Meistern der Log-Einträge (Teil 8): Fehlereinträge, die sich selbst übersetzen"

Neuer Kommentar
 

Neuer Artikel Meistern der Log-Einträge (Teil 8): Fehlereinträge, die sich selbst übersetzen :

In diesem achten Teil der Serie Meistern der Log-Einträge untersuchen wir die Implementierung mehrsprachiger Fehlermeldungen in Logify, einer leistungsstarken Protokollierungsbibliothek für MQL5. Sie lernen, wie Sie Fehler mit Kontext strukturieren, Meldungen in mehrere Sprachen übersetzen und Protokolle dynamisch nach Schweregrad formatieren können. Und das alles in einem sauberen, erweiterbaren und produktionsreifen Design.

An diesem Punkt der Reise ist es keine Überraschung, dass es bei der Protokollierung nicht nur um die Aufzeichnung von Ereignissen geht. Es geht darum, genau zu erfassen, was Ihr EA Ihnen inmitten des Wirbels von Ticks, Entscheidungen und Unwägbarkeiten, die den täglichen algorithmischen Handel bestimmen, mitzuteilen versucht.

Bei der täglichen Arbeit mit Logify ist mir etwas aufgefallen, das mich gestört hat: Die Fehlerbehandlung war noch sehr oberflächlich. Selbst mit einer robusten Formatierungsstruktur zeigten die Protokolle immer noch nur den rohen Fehlercode an, ohne irgendeinen Hinweis darauf, was er eigentlich bedeutete. Etwa so:

logify.Error("Failed to send sell order", "Order Management", "Code: "+IntegerToString(GetLastError()));
// Console:
// 2025.06.06 10:30:00 [ERROR]: (Order Management) Failed to send sell order | Code: 10016

Das Ergebnis? Eine nebulöse Botschaft. Wir wissen, wo der Fehler aufgetreten ist, aber nicht warum. Und wer hat schon einmal Dutzende von MQL5-Codes in der Dokumentation untersuchen müssen? Das habe ich früher selbst oft gemacht: Sobald ich den Fehlercode hatte, musste ich in der Dokumentation nachsehen, um herauszufinden, was wirklich passiert war. Aus dieser echten Spannung heraus entstand die Idee: Was wäre, wenn Logify den Fehler für mich interpretieren könnte? Wie wäre es, wenn ich nicht nur den Code bekäme, sondern auch seine Bedeutung in klarer, kontextualisierter Form, bereit zur Protokollierung?


Autor: joaopedrodev

 
Beide von Ihnen erstellten Bibliotheken sind hervorragend, danke für den Code.
 
Danke, ich helfe gerne. Wenn Sie Verbesserungsvorschläge haben, kontaktieren Sie mich bitte!
 
joaopedrodev #:
Danke, ich helfe gerne. Wenn Sie Verbesserungsvorschläge haben, kontaktieren Sie mich bitte!
Was soll ich tun, wenn die Protokollierung sehr häufig erfolgt, ich aber wiederholte Ausdrucke vermeiden möchte? Wenn z. B. ein Handelseröffnungssignal erkannt wird, aber der Spread zu groß ist und Dutzende von Sekunden anhält, würde die Protokollierung mindestens Dutzende oder sogar Hunderte von Malen erfolgen. Wie kann diese Situation behoben werden? Ich weiß, dass eine Lösung darin besteht, eine Variable zu verwenden, um sicherzustellen, dass das Protokoll nur einmal angezeigt wird, aber es wäre besser, wenn die Protokollierungsbibliothek dies selbst erledigen könnte. Könnten Sie einige Vorschläge machen?
 

Ich habe die Logging-Bibliothek Logify kompiliert, und nach MT5 Build 5100 gibt es mehrere Kompilierungsfehler im Zusammenhang mit Typen in CLogifyHandlerDatabase::Query . Ich glaube, Sie sollten dieses Problem bereits behoben haben.
 
Danke für die Anregungen, ich werde sie in künftigen Artikeln aufgreifen.
 
joaopedrodev #:
Danke für die Anregungen, ich werde sie in künftigen Artikeln aufgreifen.

Ein kleine Idee zu den Sprachen.

Vielleicht die englischen Originalnachrichten so anordnen, dass sie leicht mit Copy & Paste in einen Übersetzer (deepl.com oder translate.google.com) übertragen und das Ergebnis wieder ins Programm platziert werden kann. So kann sich jeder das Programm ganz leicht seine Sprache einrichten.

Deeple kennt 36 Sprachen, Google sogar ca 130.

Neuer Kommentar