Konzept: Eigene Warnungen erzeugen

[Xong]

Mahlzeit, Herrschaften!
Ich melde mich nach langer Abstinenz wieder in der Delphi-Szene zurück. :dp:

Natürlich habe ich auch gleich eine knifflige Frage.
Mein aktuelles Problem ist konzeptueller Natur.

Kurzfassung: Wie konzipiere ich eigene Warnungen?

Konkretes Beispiel:
Ich definiere eine Klasse die als Zeichenkettencontainer dienen soll. Dabei gibt es strenge Auflagen für den Zeichensatz und die -länge. [1]
Bei Aufruf der Setter-Methode dieser Klasse sollen zu lange Strings einfach auf die maximal mögliche Länge gekürzt, sowie unerlaubte Zeichen konvertiert werden. Ist solch eine Konvertierung nötig, soll die aufrufende Klasse mit einer Warnung (Achtung: nicht Fehlermeldung) davon benachrichtigt werden.
Fehler können natürlich trotzdem auftauchen und werden über Exceptions vermittelt.

Für die Warnungen allerdings sind Exceptions leider nicht geeignet, da nachfolgender Code nicht weiter ausgeführt wird.
Die Rückgabe eines Fehlercodes ist natürlich möglich, würde mMn aber durch die Kombination verschiedener Warnhinweise nur unnötig kompliziert werden.

Gibt es eine andere Möglichkeit, Warnungen zu erzeugen aber den Code trotzdem weiterlaufen zu lassen (ähnlich dem Fehlerkonzept beim Kompilieren)?
Wie wird das allgemein gelöst?

Vielleicht denke ich ja zu verworren und die Lösung ist eigentlich ganz einfach.

Danke fürs Lesen.

LG,
Xong


[1] Wen es interessiert: Ich programmiere eine DTAUS-Klasse für den elektronischen Zahlungsverkehr.

[jfheins]

Zitat:

Zitat von Xong

M
Ich definiere eine Klasse die als Zeichenkettencontainer dienen soll. Dabei gibt es strenge Auflagen für den Zeichensatz und die -länge. [1]
Bei Aufruf der Setter-Methode dieser Klasse sollen zu lange Strings einfach auf die maximal mögliche Länge gekürzt, sowie unerlaubte Zeichen konvertiert werden. Ist solch eine Konvertierung nötig, soll die aufrufende Klasse mit einer Warnung (Achtung: nicht Fehlermeldung) davon benachrichtigt werden.
Fehler können natürlich trotzdem auftauchen und werden über Exceptions vermittelt.

Wenn der übergeben String ungültig ist sollte ein Exception geworfen werden ;)

Eine Warnung, wie du sie dir grad vorstellst, gibts so nicht. Du könntest natürlich ein Event einbauen, dass dem Aufrufer solche Warnungen mitteilt. Die kann der Aufrufer dann mitloggen, oder es sein lassen. Aber trotzdem kann (wenn man das Event nicht benutzt) dann so ein Fehler auftreten wie "Ich übergebe der Klasse etwas, und die vermukst das, irgendwas stimmt da nicht"

DTAUS sagt mir jetzt nix, aber wenn es um Geld geht würde ich erst recht nicht wollen, dass da Code versucht, das ungültigen Eingabedaten irgendwas passendes zu rekonstruieren :P

[himitsu]

Die Fehlerkodes als Rückgabewerte hast du ja schon genannt,
dann bleiben noch ein Fehler-Property (a)
und eine Ereignisprozedur (b).

Fehlerproperty


A)
Ein Property in deiner Klasse, welche sich den letzen Fehler/Status merkt (als Fehlercode oder Fehlertext),
> ähnlich GetLastError
wo man dann nach Ausführen eines Befehls (z.B. einer Prozedur der Klasse) nachfragen kann, wie es gelaufen ist.

B)
Man kann eine Ereignisprozedur bei deiner Klasse registrieren ala .OnWarning (so wie .OnClick beim Button), welche dann bei einem Problem aufgerufen wird.

[Sko]

Ich bau mir für sowas auch immer gerne Ereignisprozeduren. Diese haben als Parameter meist einen Ereignistyp (i. d. R. ein Aufzählungstyp), eine Meldung und eventuell einen Fehlercode. Aber wie jfheins schon angemerkt hat: das Event muss man auch nutzen und darfs nicht vergessen, an der Stelle ist eine Exception im Vorteil.

[Blup]

Man könnte als Standardverhalten auch eine Exception vorsehen, die im Ausnahmefall durch die Eventmethode über einen Rückgabewert verhindert werden kann.

[jaenicke]

Man kann es doch einfach einstellbar machen. Wenn Property SuppressExceptions nicht gesetzt ist, dann raise ..., fertig. ;-)

[jfheins]

Man könnte auch eine Exception werfen, falls das Event nicht benutzt wird :mrgreen:

if not Assigned(OnWarning) then
raise WarningException.Create(...);

Ob das sinnvoll ist, steht auf einem anderen Blatt :stupid:

[Ralf Kaiser]

Zitat:

Zitat von Xong

Gibt es eine andere Möglichkeit, Warnungen zu erzeugen aber den Code trotzdem weiterlaufen zu lassen (ähnlich dem Fehlerkonzept beim Kompilieren)?

Sollen diese Warnungen denn irgendwo angezeigt werden? Sieht der Benutzer die Warnungen und kann dann irgendwelche Massnahmen ergreifen? (wenn beim compillieren Warnungen angezeigt werden dann kann man diese ja nacher auch beheben, idem man den Code ändert und anpasst)

Wenn der Benutzer die Warnungen irgendwo sehen kann dann bietet sich doch eine Loggingausgabe an die irgendwo im Programmfenster angezeigt wird:

Zitat:

[Nachricht]: Vorgang gestartet
[Nachricht]: Beginne mit dem Import
[Warnung]: Datei enthält falsche Zeichen
[Nachricht]: Import beendet
[Nachricht]: Beim letzten Import wurde eine Warnung erzeugt!

Analog zum compillieren würde eine Meldungsliste angezeigt die den aktuellen Vorgang beschreibt und Warnungen eventuell noch farblich hervorhebt.

Im einfachsten Fall werden die Warnungen in einer Stringliste gespeichert dei, getriggert durch ein Event, vom Hauptprogramm ausgegeben wird (oder man greift auf fertige Logging-Lösungen zurück)

[Xong]

Ich danke euch für eure Antworten.

Da ist ja auch schon viel Schönes dabei.

Ich habe inzwischen auch einen kleinen Beispielcode.
Es gibt eine Setter-Methode, die einen String entgegen nimmt und nach strengen Vorschriften konvertiert.
Dabei sind die Konvertierungen nicht weiter schlimm, sollen aber dem Anwender wenigstens mitgeteilt werden:

Delphi-Quellcode:

procedure TDtausDataType.SetValue(v: String);
var i: Integer;
begin
  // convert to upper case
  fValue := UpperCase(v);

  // lower case characters detected
  if StrComp(PAnsiChar(v), PAnsiChar(fValue)) <> 0 then
    ShowMessage('Klein- zu Großbuchstaben konvertiert!');

  // check each character
  for i:=1 to Length(v) do
  begin
    { Hier folgt eine weitere Überprüfung jedes einzelnen Zeichens,
      ob es im "DTAUS-Zeichensatz" erlaubt ist.
      Nicht erlaubte Zeichen sollen dabei mit Leerzeichen ersetzt werden.
      Bei bestimmten Daten (wie z. B. Kontonummer) ist das ein Fehler,
      bei anderen (wie z. B. Verwendungszweck) lediglich eine Warnung.
    }
  end;
end;

Wie teile ich nun der aufrufenden Klasse diese Warnungen mit. (Fehler werden über Exceptions behandelt.)

Meine Idee wäre folgende:
Es gibt einen Container für Warnungen, der entsprechend gefüllt wird.
Bei Auftreten einer Warnung trägt die Setter-Methode diese ein und teilt der aufrufenden Instanz über eine Event mit, dass Warnungen aufgetreten sind.

Anmerkungen oder Bedenken?


Danke für eure Anregungen.

[Ralf Kaiser]

Zitat:

Zitat von Xong

Meine Idee wäre folgende:
Es gibt einen Container für Warnungen, der entsprechend gefüllt wird.
Bei Auftreten einer Warnung trägt die Setter-Methode diese ein und teilt der aufrufenden Instanz über eine Event mit, dass Warnungen aufgetreten sind.

Anmerkungen oder Bedenken?

Genau das hatte ich im vorherigen Beitrag vorgeschlagen. :wink: Als "Container" hatte ich eine TStringList vorgeschlagen aber da kann man eventuell auch etwas "intelligenteres" nehmen. So könnte man den "TwarnungsContainer" so implementieren, dass er immer wenn eine Warnung hinzugefügt wird ein Event triggert und so selbst das Hauptprogramm benachrichtigt. Dann muss sich deine Klasse nicht mehr um dieses Detail kümmern.