Fehler-, Hinweis- und Warnmeldung ordentlich verwalten

[Aviator]

Hallo Delphianer,

ich hätte mal wieder eine Frage zu dem Thema "Best Practice". Wie verwaltet man am besten und am sinnvollsten Fehler-, Hinweis- und Warnmeldungen? In meinem Fall handelt es sich nicht um eine Anwendung, welche in mehreren Sprachen zur Verfügung stehen muss. Wenn das aber mit einer Lösung eurerseits auch abgefrühstückt werden kann, dann immer her damit. :)

Es gibt ja mehrere Ansätze dazu:

• Speicherung direkt im SourceCode
• Speicherung in einer Datenbank
• Speicherung in einer externen Datei
• ...

Zur Zeit habe ich meine Meldungen als Konstanten immer in einer Projektdatei abgelegt. Diese wurden dann beim Aufruf eines MessageDlg einfach nur übergeben (z.B. so

Delphi-Quellcode:

MessageDlg(ERROR_SOMEERROR, mtError, [mbOk], 0);

).

In einem anderen Projekt wollte ich dann auf ErrorCodes umsteigen welche intern und auch von DLLs beim Aufruf von Funktionen zurückgegeben werden sollen. Diese ErrorCodes müssen aber ja auch wieder zu einer lesbaren Meldung umgewandelt werden. Also hatte ich auch hier eine bzw. mehrere Konstanten Dateien (eine für Error, eine für Warnungen, eine für Hinweise), in der jeweils der ErrorCode und die zugehörige Meldung in einem TDictionary gespeichert wurden.

So eine Datei wird dann natürlich schnell übersichtlich und man muss auch immer auf die korrekte Fortschreibung der Fehlercodes achten. Ein automatisches Hochzählen der ErrorCodes (wie das bei der Speicherung in einer SQL Datenbank gemacht werden könnte) kann auch ganz schnell ins Auge gehen. Denn dann passen die im SourceCode ausgegebenen Fehlercodes evtl. nicht mehr zu den Meldungen die in der Tabelle stehen.


Meine Frage an euch: Wie löst ihr so etwas? Was hat sich bei größeren Projekten bei euch bewährt? Ein Beispiel zu der jeweiligen Lösung wäre (je nach Schwierigkeitsgrad) auch ganz schön. :)

[Sailor]

Ich verwende keine numerischen Fehlercodes, sondern Key-Value-Paare "Name=Value". Der Name wird als Fehlercode evtl. zusammen mit Parametern (z.B. in Frage kommender Filename, Warning/Error/Hint) der Fehlermitteilungsroutine übergeben, die aus dem Value und evtl. Parametern die aktuelle Fehlermitteilung zusammenbaut und ausgibt. Die Key-Value-Paare sind aktuell in einer Datei abgelegt, die beim Programmstart geladen und aufbereitet wird. Mehrsprachigkeit läßt sich so ebenfalls leicht erreichen.

[KodeZwerg]

Oje, da bin ich ja total oldschool noch eingestellt.
Konstanten für Fehlernummern im Source + dll Dateien die lediglich lokalisierte ResourcenStrings beinhaltet.

Da mich das Thema auch Interessiert bin ich mal still und hoffe da kommt noch mehr.

[Der schöne Günther]

Früher war es in einer einfachen Textdatei. Zeilennummer war Fehler/Alarmnummer. Mehrsprachigkeit war gegeben indem einfach eine andere Datei geladen wurde.

Vorteil: Jeder Techniker kann die Texte nachträglich noch abändern wenn sich der Kunde in Finnland oder China über die Übersetzung kaputtlacht und sagt wie es eigentlich heißen müsste.

Nachteil: Verrutsche Zeilen und nichts stimmt mehr. Encoding-Probleme wenn jemand glaubt z.B. eine russische Übersetzung als ANSI speichern zu müssen.


Jetzt: So wie der KodeZwerg es macht: Resourcestrings im Programm. Die werden in einem Array gespeichert sodass auch der alte Code der z.B. auf "Zeile 114" zugreift noch funktioniert. Um die Magic Numbers loszuwerden sollte man natürlich aber auf Konstanten mit Namen umsteigen.
Die anderen Sprachen wurden in .po/.mo-Dateien ausgelagert.

Vorteil: Übersetzungen in andere Sprachen lassen sich jetzt mit besseren Tools als Notepad bearbeiten. Keine Kodierungs-Probleme mehr. Automatischer Export der Übersetzungen in Excel-Listen für Übersetzer/Vertreter.

Nachteil: Nix, bin wunschlos glücklich. Das umzustellen war auch kein großer Aufwand.




PS: Klammere dich nicht zu sehr an die Nummern. Die Nummern helfen dir wenn am Telefon ein Kunde in gebrochenem Englisch dir sagen will was für ein Fehler auftrat, dafür sind die super. Niemand zwingt dich dass nach einem Eintrag "123" unbedingt eine "124" folgen muss. Thematisch hält man das alles sowieso nie lange zusammen.

[Sherlock]

Ich habe gar keine Fehlernummern. Die Meldungen sind alle Resourcestrings im Code. Warum habe ich keine Nummern? 1. Faulheit und b) "Was Ihre Applikation hat mindestens 1047 andere mögliche Fehlermeldungen? Nein, sowas kaufe ich nicht."

Sherlock

[p80286]

Zitat:

Zitat von Sherlock (Beitrag 1414058)

Ich habe gar keine Fehlernummern. Die Meldungen sind alle Resourcestrings im Code. Warum habe ich keine Nummern? 1. Faulheit und b) "Was Ihre Applikation hat mindestens 1047 andere mögliche Fehlermeldungen? Nein, sowas kaufe ich nicht."

Sherlock

Für diese Kunden reicht eine Fehlermeldung:
Error 0001 System activated without Response on user interface:mrgreen:

Gruß
K-H

[Der schöne Günther]

Also ich sehe nur bei mir im industriellen Bereich, hier hat von jedem Hersteller jedes Gerät zu einem Fehler/Alarm eine Nummer.

Wenn man einfach nur Texte nimmt weiß man spätestens bei Übersetzungen (vor allem wenn die mal angepasst wurden) nicht mehr, wovon jemand spricht. Meint er jetzt das oder das? Eine Nummer kann einem selbst ein Chinese der keinen Brocken Englisch kann durchgeben oder abfotografieren und jeder weiß genau worum es geht.


Natürlich macht es keinen Sinn offensichtliche Oberflächen-Bedienfehler wie "Bitte geben Sie gefälligst eine Zahl ein!" eine Nummer zu verpassen, aber halt Dingen wie "Überdruck im Kessel, bring dich in Sicherheit".

[Aviator]

Hi und danke für die Rückmeldung. Eigentlich wollte ich gestern Abend ja noch antworten, habe das aber zeitlich nicht mehr geschafft. :|

Das mit den Resourcestrings wollte ich mir eigentlich immer mal anschauen, bin aber nie wirklich dazu gekommen. Ich würde von einer DLL gerne einen ErrorCode zurückbekommen und diesen in meiner Hauptanwendung dann in eine Message übersetzen wollen. Das Gleiche natürlich dann auch in der eigentlichen Hauptanwendung.

Müssen die ResourceStrings in eine DLL ausgelagert werden? Ich habe kein Problem damit, es interessiert mich nur.

Könnte mir da jemand mal ein kleines Beispielprojekt zusammenfummeln bei dem ich mir das mal anschauen kann? Wichtig wären mir die ErrorCodes damit, wie von Günther angesprochen, einfach nur die Nummer durchgegeben werden müsste wenn es mal zu einem Fehler kommt.

Vorab besten Dank! :thumb:

[Der schöne Günther]

Ist doch super wenn die schön übersichtlich eine eindeutige Nummer zurückgibt - Wenn man jetzt noch Texte dort hineinfummelt hat man nichts gewonnen.

[Aviator]

Zitat:

Zitat von Der schöne Günther (Beitrag 1414076)

Ist doch super wenn die schön übersichtlich eine eindeutige Nummer zurückgibt - Wenn man jetzt noch Texte dort hineinfummelt hat man nichts gewonnen.

Ich glaube da haben wir uns falsch verstanden. Die DLL soll einen ErrorCode zurückgeben. Mehr nicht.

Die Hauptanwendung soll das jetzt aber in eine für den Benutzer lesbare Fehlermeldung umwandeln. Das ist doch bei dir sicherlich genau so, oder?

[KodeZwerg]

Zitat:

Zitat von Aviator (Beitrag 1414074)

Hi und danke für die Rückmeldung. Eigentlich wollte ich gestern Abend ja noch antworten, habe das aber zeitlich nicht mehr geschafft. :|

Das mit den Resourcestrings wollte ich mir eigentlich immer mal anschauen, bin aber nie wirklich dazu gekommen. Ich würde von einer DLL gerne einen ErrorCode zurückbekommen und diesen in meiner Hauptanwendung dann in eine Message übersetzen wollen. Das Gleiche natürlich dann auch in der eigentlichen Hauptanwendung.

Müssen die ResourceStrings in eine DLL ausgelagert werden? Ich habe kein Problem damit, es interessiert mich nur.

Könnte mir da jemand mal ein kleines Beispielprojekt zusammenfummeln bei dem ich mir das mal anschauen kann? Wichtig wären mir die ErrorCodes damit, wie von Günther angesprochen, einfach nur die Nummer durchgegeben werden müsste wenn es mal zu einem Fehler kommt.

Vorab besten Dank! :thumb:

>>Könnte mir da jemand mal ein kleines Beispielprojekt zusammenfummeln bei dem ich mir das mal anschauen kann?
man muss nichts fummeln da schon so etwas hier existiert.
Hier gibt es ein Beispiel aus diesem Forum


>>Müssen die ResourceStrings in eine DLL ausgelagert werden? Ich habe kein Problem damit, es interessiert mich nur.
Nein, aber wenn man Multilanguage macht, ergibt das alles mehr Sinn es in DLL auszulagern.

[Aviator]

Den Thread und die Beispiele habe ich gesehen. Funktioniert bei mir aber leider nicht. Bekomme das Projekt nicht richtig geöffnet, bzw. es funktioniert das dem Kompilieren nicht.

Liegt aber wohl daran, dass es schon 15 Jahre alt ist und mit einer uralten Version gemacht wurde. Das Prinzip mag vielleicht noch das Gleiche sein, aber mit dem "Beispielprojekt" komme ich nicht wirklich zurecht.

[Der schöne Günther]

So wie ich es verstanden habe:

Der Unterschied zwischen

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
const
   welcomeMessage = 'Hallo Welt';
begin
   ShowMessage(welcomeMessage);
end;

und

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
resourcestring
   welcomeMessage = 'Hallo Welt';
begin
   ShowMessage(welcomeMessage);
end;

ist einzig und allein wie der Compiler das 'Hallo Welt' in die .exe-Datei einbettet. Du kannst z.B. den Text mit einem Editor nachträglich anpassen ohne die .exe neu zu kompilieren:
Anhang 50025

Die Geschichte mit DLL-Dateien ist, soweit ich das mal gesehen habe, dass man die Resourcen-Strings in eine externe DLL-Datei auslagert und die Sprache umstellt indem man die DLL tauscht.
Was ist daran jetzt besser als z.B. als an einer Textdatei? Habe ich auch nicht verstanden.


Was die

Delphi-Quellcode:

resourcestring

-Geschichte so toll macht sind Tools wie z.B. dxGetText welche deine Delphi-Projekte nach Resourcestrings durchsuchen, in .po-Dateien extrahieren und dir eine Methode anbieten wie du in der Delphi-Runtime die Sprachauflösung umschalten kannst sodass du nur einmal sagst

Delphi-Quellcode:

useLanguage('EN')

und in dem resourceString plötzlich Bonjour le monde drinsteht.


Hört sich wahrscheinlich immer noch völlig abstrakt an. Probier einfach mal dxGetText aus. Da kümmert man sich um den ganzen Kram nicht mehr.

[Aviator]

Das habe ich soweit verstanden. Aber wie kombiniere ich das jetzt noch mit einem ErrorCode? Muss ich mir da selbst wieder ein Dictionary bauen das mir den ErrorCode zu einem ResourceString umwandelt oder geht das irgendwie eleganter?
EDIT: Weil dann könnte ich theoretisch auch bei meiner bisherigen Lösung bleiben. Da mache ich das nämlich auch so. Ist nur eben sehr viel Handarbeit (die ich vermeiden wollte).

Die Zahlen der ResourceStrings kann man wohl nicht nehmen wie ich das gesehen habe da sich diese wohl beim erneuten Kompilieren der Anwendung verschieben könnten. Und eigentlich wollte ich bei den ErrorCodes mit 0 (für kein Error) anfangen und dann nach oben zählen.

[freimatz]

Zitat:

Zitat von Der schöne Günther (Beitrag 1414099)

Die Geschichte mit DLL-Dateien ist, soweit ich das mal gesehen habe, dass man die Resourcen-Strings in eine externe DLL-Datei auslagert und die Sprache umstellt indem man die DLL tauscht.
Was ist daran jetzt besser als z.B. als an einer Textdatei? Habe ich auch nicht verstanden.

Vorteil einer dll ist, dass wenn man nicht nur Texte sondern auch Bilder u.a. hat die da auch noch unterbringen kann.
Nachteil einer dll kann sein, dass beim Austauschen auch mal ein Virenschutzprogramm stört. (selber erlebt)

Leider ist das Thema sehr unübersichtlichund jeder kocht sei eigenes Süppchen. Ich habe damals etwas von Turbopower übernommen.

[KodeZwerg]

Hallo Aviator,

am einfachsten erklärt sich das mit den DLL Dateien so:
Betrachte die als eine Art binäre INI-Datei, mit dem Vorteil das man innerhalb der IDE alles auf anhieb zusammen hat.

Wie vom Vorredner hat es auch den Vorteil das man Daten jeglicher Art mit reinquetschen kann, geht prinzipiell auch mit INI aber ist doch etwas weit entfernt von "es macht Sinn".

Mit AntiViren Programme bei reinen ResourceString DLLs habe ich bis jetzt noch keine negativen Erfahrung sammeln können, aber klar ist es vorstellbar.

Wenn Du tatsächlich eine Demo benötigst, schreib ich das 15 Jahre alte Demo um so das auch ein Tokyo damit klarkommt, aber wie Du schon richtig bemerkt hast, es bleibt alles beim alten Prinzip, ResourceString einen qualifizierten Identifier geben, Text rein, im Project Source auf die ID per Konstante oder wie auch immer zugreifen, fertig, bei Sprachänderung einfach "Sprache_DE.dll" mit "Sprache_EN.dll" austauschen, so als Beispiel. Alles ziemlich einfach, ich bin auch der Meinung das Delphi sowas onboard dabei hat, so einen DLL Sprach-Baukasten (ist das eventuell da aufm Photo?)..... ich selbst habs immer oldschool per Notepad++ erledigt, kommt ja kein Code rein, nur ResourceStrings.

Man kann auch, damit Leute selbst handanlegen können, das Prinzip auf INI oder XML anwenden, mit einer reinen Text-Datei die auf Zeile X für Text X, sowas habe ich noch nie gemacht, das wäre mir auch zu Fehleranfällig, bei INI kannst Du wenigstens einen Default Wert in Source aufnehmen, bei XML das weiß ich gar nicht ob das auch geht.

Ist auf jeden Fall einen Blick Wert sich damit mal näher zu Beschäftigen, einmal drinne ists wie Fahradfahren, easy.

Ich bin ehrlich gesagt davon ausgegangen dass das mit DLL mehr als Überholt ist, ich mache das seit meinem Umstieg von Pascal nach Delphi, also schon eine Weile her.... dadurch das es so einfach ist, habe ich mich nie wirklich um ein upgrade bemüht.

[Aviator]

Hallo zusammen,

ich habe jetzt mal noch einen Tag darüber nachgedacht und ein paar Dinge ausprobiert. Ich bin jetzt soweit, dass ich die Meldungen wohl als Strings in der Datenbank ablege und dann mit einer Konstante aus dem SourceCode darauf verweise. In der Datenbank steht dazu auch noch, welcher MessageType das ist. Also Information, Warning, Error, Confirmation. Beim Start der Anwendung werden diese Strings dann eingelesen und in einer MessageHelper Klasse verwaltet. Wenn ich nun eine Meldung anzeigen will, übergeben ich nur noch den ErrorCode und erhalte direkt die Message.

Ich denke, dass das für mich eine praktikable Lösung ist. Das mit den Resourcestrings werde ich aber auf jeden Fall im Hinterkopf behalten und mir das dann auch bei Gelegenheit nochmal anschauen.

Danke für den Input. (Obwohl ich die Zuordnung von ErrorCode/Konstante zu ResourceString noch nicht so richtig auf dem Schirm habe.)

[Schokohase]

Zitat:

Zitat von KodeZwerg (Beitrag 1414149)

Man kann auch, damit Leute selbst handanlegen können, das Prinzip auf INI oder XML anwenden, mit einer reinen Text-Datei die auf Zeile X für Text X, sowas habe ich noch nie gemacht, das wäre mir auch zu Fehleranfällig, bei INI kannst Du wenigstens einen Default Wert in Source aufnehmen, bei XML das weiß ich gar nicht ob das auch geht.

Warum sollte das bei XML nicht gehen? Das nennt sich programmieren und dann gibt es auch dort einen Default-Wert zurück. Schau doch mal in den Source wie das bei den Ini-Dateien gemacht wird (mit dem Default-Wert).

Kleiner Hinweis: Die Datei selber kann es nicht.

[KodeZwerg]

Zitat:

Zitat von Schokohase (Beitrag 1414356)

Zitat:

Zitat von KodeZwerg (Beitrag 1414149)

Man kann auch, damit Leute selbst handanlegen können, das Prinzip auf INI oder XML anwenden, mit einer reinen Text-Datei die auf Zeile X für Text X, sowas habe ich noch nie gemacht, das wäre mir auch zu Fehleranfällig, bei INI kannst Du wenigstens einen Default Wert in Source aufnehmen, bei XML das weiß ich gar nicht ob das auch geht.

Warum sollte das bei XML nicht gehen? Das nennt sich programmieren und dann gibt es auch dort einen Default-Wert zurück. Schau doch mal in den Source wie das bei den Ini-Dateien gemacht wird (mit dem Default-Wert).

Kleiner Hinweis: Die Datei selber kann es nicht.

Kleiner Hinweis: Die Datei selber wird es nie alleine können.

Delphi-Quellcode:

Ini.ReadString('SEKTION', 'SCHLÜSSEL', 'GRUNDWERT');

Ich sagte/meinte, das ich nicht weiß ob XML eine ähnlich einfache basis-funktion bietet ohne selbst was dafür zu programmieren. So schwer zu verstehen?
Das wenn etwas fehlen sollte man es sich selbst reinprogrammieren kann, dieses Möglichkeit ist mir bewusst.