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 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 von 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

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

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!

[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 von 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.

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?