Fehler-, Hinweis- und Warnmeldung ordentlich verwalten

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

[KodeZwerg]

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

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