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.

[himitsu]

Eine StringList hat doch ein OnChange?

Da kann also ein Event angegeben werden .. eventuell ein Porperty in der Basisklasse, welches das dann bei der internen StringListe einträgt.
Oder die StringListe meldet Änderungen an die Basisklasse und diese wiederum leidet das Event weiter.
Oder man baus in seine Klasse eine interne SetzeWarnung-Prozedur, welche die Warnung in die StringList einträgt und das Event auslöst.
...

[Xong]

Zitat:

Zitat von Alfi001

Genau das hatte ich im vorherigen Beitrag vorgeschlagen.

Ich wollte nicht unterschlagen, dass du mir sehr bei der Suche nach einem passenden Konzept geholfen hast.

Also ein dickes Dankeschön! :stupid:

[Ralf Kaiser]

Zitat:

Zitat von himitsu

Eine StringList hat doch ein OnChange?

Stimmt! Ist mir auch jetzt gerade erst aufgefallen. Wann wurde das denn eingeführt? :gruebel: Eventuell sollte ich mir von Delphi-Version zu Delphi-Version mal die Neuerungen (genauer) ansehen...

Damit wäre die TStringList auch schon "intelligent" genug als Container für die Warnungen.

[nahpets]

Hallo,

mal so aus dem Bauch:

Die Klasse TDtausDataType bekommt eine Stringliste, in die sie die Warnungen reinschreibt.
Wenn sie mit ihrem Job fertig ist und es sind Warnungen vorhanden, schmeißt sie eine Ausnahme vom Type EWarnungenGefunden (oder so). Das aufrufende Programm muss diese Ausnahme abfangen und die Liste (wie auch immer) ausgeben.

Wird das Abfangen dieser Ausnahme vom Programmierer "vergessen", ärgert sich der Anwender und der Programmierer muss nachsitzen.

Bei einem Event muss sichergestellt sein, dass die "Nichtzuordnung" einer entsprechenden OnEvent-Methode zu einem Fehler führt.

[s.h.a.r.k]

Zitat:

Zitat von nahpets

Hallo,

mal so aus dem Bauch:

Die Klasse TDtausDataType bekommt eine Stringliste, in die sie die Warnungen reinschreibt.
Wenn sie mit ihrem Job fertig ist und es sind Warnungen vorhanden, schmeißt sie eine Ausnahme vom Type EWarnungenGefunden (oder so). Das aufrufende Programm muss diese Ausnahme abfangen und die Liste (wie auch immer) ausgeben.

Wird das Abfangen dieser Ausnahme vom Programmierer "vergessen", ärgert sich der Anwender und der Programmierer muss nachsitzen.

Bei einem Event muss sichergestellt sein, dass die "Nichtzuordnung" einer entsprechenden OnEvent-Methode zu einem Fehler führt.

genau das hätte ich auch auch vorgeschlagen. schreib doch einfach ein interface für deine klasse, die die entsprechenden methoden und internen variablen schon integriert hat. dann kannst du das system auch bei anderen klassen verwenden. kurz und knapp brauchst du halt das folgende:

• container für die warnungen (was da am besten ist, sei mal dahin gestellt!)
• push-methode
• pop-methode
• clear-methode
• eine methode, die du am ende einer entsprechenden methode aufrufst, die prüft, ob mind. ein eintrag in der warnungs-liste vorhanden ist, und dann eine exception wirft.

[Blup]

Ich bin der Meinung, daß die Anwendung die Möglichkeit haben sollte, auf jedes Ereignis noch im laufenden Prozess zu reagieren. Dafür muss diese über das Ereignis benachrichtigt werden, wenn es stattfindet und nicht erst wenn der gesamte Prozess beendet wurde. Damit die Anwendung differenzieren kann, sollte neben dem Meldungstext auch ein Code mitgeliefert werden. Damit hat die Anwendung auch die Möglichkeit mit einer eigenen Exception zu reagieren.

Delphi-Quellcode:

type
  TDtausOnError = procedure (Sender: TObject; ACode: TErrorCode; const AMsg: string) of Object;
  TDtausOnNotify = procedure (Sender: TObject; ACode: TErrorCode; const AMsg: string; var AExcept: Boolean) of Object;

  TDtausDataType = class()
  private
    FOnError: TDtausOnError;
    FOnNotify: TDtausOnNotify;
  protected
    procedure DoOnError(ACode: TErrorCode; const AMsg: string); virtual;
    procedure DoOnNotify(ACode: TErrorCode; const AMsg: string; AExcept: Boolean = False); virtual;
  public
    property OnError: TDtausOnError read FOnError write FOnError;
    property OnNotify: TDtausOnNotify read FOnNotify write FOnNotify;
  end;

procedure TDtausDataType.DoOnError(ACode: TErrorCode; AMsg: string);
begin
  if Assigned(FOnError) then
    FOnError(Self, ACode, AMsg);

  raise TDtausExcetpion.Create(ACode, AMsg);
end;

procedure TDtausDataType.DoOnNotify(ACode: TErrorCode; AMsg: string; AExcept: Boolean = False);
begin
  if Assigned(FOnNotify) then
    FOnNotify(Self, ACode, AMsg, AExcept);

  if AExcept then
    raise TDtausExcetpion.Create(ACode, AMsg);
end;


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
    DoOnNotify(1, '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. 
    } 
    {immer Exception auslösen}
    DoOnError(2, 'Ungültige Zeichen im Feld xxx');

    {oder normalerweise Exception auslösen, es sei den die Anwendung sagt das ist ok}
    DoOnNotify(3, 'Ungültige Zeichen im Feld yyy', True);

    {oder normalerweise keine Exception auslösen, es sei den die Anwendung sagt das ist nicht ok}
    DoOnNotify(4, 'Ungültige Zeichen im Feld zzz', False);

  end; 
end;

ErrorCode und Meldungstext sollten natürlich vordefinierte Konstanten sein, wobei der Text mit Format z.B. um den Feldnamen ergänzt werden könnte.