dxGetText: Exceptions zu lokalisieren war ein Fehler, oder?

[Der schöne Günther]

Ich habe folgendes Szenario: Prozesstechnische Exceptions haben über das Feld Message einen aussagekräftigen Text. Manchmal bekommt der Benutzer den auch zu sehen, manchmal wird der nur gelogged. Ganz simpel:

Delphi-Quellcode:

type
   EDeviceException = class(System.SysUtils.Exception)

resourcestring   
   ovenBrokeDownAgainFmt = 'No cookies for you because the oven broke down for the %dth time';

implementation

   procedure makeCookies();
   begin
      if oven.isMalfunctioning() then begin
         Inc(malfunctioningTimes);
         raise EDeviceException.CreateFmt(ovenBrokeDownAgainFmt, [malfunctioningTimes]);
      end;
   end;
end;

Das Problem: Wenn die Anwendung jetzt auf Mondsprache läuft steht in

Delphi-Quellcode:

ovenBrokeDownAgainFmt

natürlich etwas anderes drin (z.B. "あなたのためのクッキーをオーブンは％d 番目の時間のために決裂していないので、"). Das ist erst einmal gut wenn der Nutzer das auf dem Bildschirm zu sehen bekommt. Allerdings ist es ziemlich blöd wenn jemand aus dem Support sich Logs anschaut und dort steht unverständliche Fremdsprache.

Die Exception wird durch einen eigene Prozedur für

Delphi-Quellcode:

Application.OnException

gelogged. Zu dem Zeitpunkt hat man nur noch sein Exception-Objekt in welchem dieser String bereits fest eingebacken ist. Ich muss nun irgendwie "rückübersetzen".

Kann man, mit dxGetText, irgendwie bewerkstelligen? Ich finde nichts. :x

[TiGü]

Zum Titel: Ja!
Am Besten für künftige Versionen von resourcestring auf const stellen.
Das sind ja eh interne Fehlermeldungen, die den Benutzer nichts angehen (sollten).

Wird in den Logs nicht noch zusätzlich der Typ der Exception abgespeichert?
Also hier jetzt die EDeviceException? Oder loggst du nur die Message?

[Der schöne Günther]

Es ist leider sehr viel der Basistyp

Delphi-Quellcode:

EDeviceException

, nicht z.B.

Delphi-Quellcode:

EOvenIsMalfunctioningException

.

Alles von diesem Basistyp bekommt der Nutzer auch angezeigt. Die Exception-Message ist z.B. "Der Ofen kann nicht heizen wenn die Klappe offen ist".

Im Logfile steht Zeit, Exception-Klasse, der Text und der Callstack. Für einen Entwickler ist die Sache damit klar, jemand aus dem Support kann aber nur mit der Nachricht etwas anfangen.

[Uwe Raabe]

Wie wird die Exception denn angezeigt? Benutzt du das interne Verfahren, sowas wie madExcept oder was eigenes?

[Der schöne Günther]

Nein, das ist einfach nur ein selbst gebautes VCL-Fenster mit einem traurigen Smiley, dem Exception-Text und einem Button für eine Diagnose-Zip-Datei auf einen Stick zu speichern.

Warum, was würde das ändern?

Aber so wie es aussieht habe ich schon eine Lösung: :cheers:

Ein Ressourcenstring ist erst einmal ein TResStringRec und kein String!

Ich habe der Exception-Oberklasse also einen neunen Konstruktor hinzugefügt:

Delphi-Quellcode:

   EDeviceException = class(Exception)
      public var
         resStr: PResStringRec;
      public
         constructor Create(const resStr: PResStringRec); {$If Defined(Test)}overload;{$Endif}
   end;

constructor EDeviceException.Create(const resStr: PResStringRec);
var
   translated: String;
begin
   self.resStr := resStr;

   translated := System.LoadResString(resStr);
   inherited Create(translated);
end

.

Heißt: Es geht weiter wie bislang. Aber das Exception-Objekt hat jetzt noch einen Verweis auf den originalen Ressourcen-String. Vorausgesetzt ich sage fortan nicht mehr

Delphi-Quellcode:

raise EDeviceException(someText)

sondern

Delphi-Quellcode:

raise EDeviceException(@someText)

Beim Loggen der Exception kann ich mich dann an diesem PResStringRec wieder zu einem englischen oder deutschen Text hangeln.

Jetzt darf ich nur den CreateFmt-Konstruktor nicht vergessen und dann sieht das schon sehr gut aus :bounce1:

[Uwe Raabe]

Wären nicht diese Konstruktornamen besser geeignet?

CreateRes
CreateResFmt
CreateResFmtHelp

[Der schöne Günther]

Wie konnte ich das übersehen!

Vielen Dank, das nimmt ja ein echtes Happy End :love: