Fehler vorbeugen vs Code aufblähen

[.chicken]

Hi, also ich hab im Moment aufgrund einer Verletzung wieder Zeit für Delphi, die ich sonst leider nur sehr sporadisch finde.

Und nun ist mir eine Frage gekommen. Ich hab ein kleines Spiel programmiert, in dem zufällig ein 2D Level generiert wird.
Mit Decke, Boden und fliegenden Boxen als Hindernisse.
Man kann diverse Einstellungen vornehmen, wie Dicke der Boxen und sowas.
Bei bestimmten Einstellungen, kann es also vorkommen, dass zB die Decke höher ist als das Level ansich, somit das gesamte Level aus der Decke besteht.
Inwiefern meint ihr sollte man sowas vorbeugen? Ich könnte natürlich für jede dieser Property eine Setter-Prozedur schreiben, in der der neue Wert erst auf gültigkeit getestet wird, aber meint ihr das macht Sinn? Dadurch würde ich unzählig mehr Zeilen an Code erhalten. Wie macht ihr sowas?

Möchte die LevelUnit so unabhängig wie möglich und somit auch so komfortabel wie möglich halten, deswegen die Frage :)

Grüße .ch!cken

[mkinzler]

Ja und bei dem knapp bemessenen Speicher heutzutage bekommt man dann schnell Probleme. :lol:
Nein, es macht schon Sinn Eingaben usw. auf Gültigkeit zu überprüfen.

[.chicken]

Hehe, ok. Ich halte Code nur gerne kurz, weil er für mich dann wesentlich übersichtlicher bleibt. Aber gut, ich sollte wohl nicht am falschen Ende sparen... :-\

[mkinzler]

Sparst du dir die Überprüfung, dann können woanders Nebeneffekte entstehen, welche dann schwer auf die wirkliche Ursache schließen lassen. Und soviele Properties werden es ja auch nicht sein.

[sx2008]

Dafür gibt es doch die Assert-Anweisung !!
Damit stellt man sicher, dass Ein- und Ausgabeparameter innerhalb gültiger Limits liegen.
Und wenn das Programm gereift ist und ohne Fehler läuft, kann man den Ballast ganz einfach in den Projektoptionen abschalten.
Ich sehe immer wieder grössere Projekte ohne eine einzige Assert-Anweisung.
Dementsprechend schlecht ist dann meist auch die Software Qualität.

Beispiel für Assert-Verwendung:

Delphi-Quellcode:

procedure ResizeForm(form:TCustomForm; x,y : integer);
begin
  Assert(Assigned(form));  // Objektzeiger sollte man immer prüfen
  Assert(x > 0, 'ResizeForm: x out of range');  // man kann zusätzlichen Text angeben
  Assert(y > 0);
  // und hier geht der normale Code los
  ..

[mkinzler]

U.U. ist es aber trotzdem besser, falsche Werte schon gar nicht speichern.

[RavenIV]

Also ich finde es auch besser, Fehler erst garnicht auftreten zu lassen.
z.B. sollte ein Eingabe-Feld für Zahlen erst gar keine Buchstaben akzeptieren.
Bzw. beim Verlassen der Form (mit OK) sollte dann zumindest eine Fehlermeldung kommen.

Natürlich kann man an jedem Ecken eine Exception provozieren, das finde ich aber nicht professionell.
Exceptions sind für nicht vorhersehbare Fehler da.
z.B. Netzwerk bricht zusammen, ein Laufwerk ist nicht mehr verfügbar, DB kackt ab.

[3_of_8]

Naja, stell dir folgendes vor:

Du hast eine Klasse TWuppdiLoader, die eine Datei vom Typ Wuppdi Laden soll. In der Dateitypspezifikation steht eine CRC32-Prüfsumme. Die stimmt aber nicht mit der Datei überein. Was machst du da? Du könntest jetzt die Funktion beenden und einen Statuscode zurückgeben (z.B. ein Set mit den aufgetretenen Fehlern) oder ein Feld in der Klasse setzen. Aber was ist, wenn der Fehler in irgendeiner Funktion weit verschachtelt auftritt? Dann brauchst du nach jedem Funktionsaufruf sowas wie if FError then exit;

Da ist eine Exception mehr als angemessen, ich würde sogar sagen, für gute Programmierung unausweichlich.

[mkinzler]

In diesem Fall würde er falsche Werte in der Klasse speichern, und bei jeder Auswertung der Werte ein exception werfen. Hier wäre eine Überprüfung der werte vor dem speichern sicherlich sinnvoll.

[phXql]

Zitat:

Zitat von sx2008

Dafür gibt es doch die Assert-Anweisung !!
Damit stellt man sicher, dass Ein- und Ausgabeparameter innerhalb gültiger Limits liegen.
Und wenn das Programm gereift ist und ohne Fehler läuft, kann man den Ballast ganz einfach in den Projektoptionen abschalten.
Ich sehe immer wieder grössere Projekte ohne eine einzige Assert-Anweisung.
Dementsprechend schlecht ist dann meist auch die Software Qualität.

Beispiel für Assert-Verwendung:

Delphi-Quellcode:

procedure ResizeForm(form:TCustomForm; x,y : integer);
begin
  Assert(Assigned(form));  // Objektzeiger sollte man immer prüfen
  Assert(x > 0, 'ResizeForm: x out of range');  // man kann zusätzlichen Text angeben
  Assert(y > 0);
  // und hier geht der normale Code los
  ..

Asserts sind meines Wissens nur für Eigenschaften, die man garantieren kann, dass sie zutreffen.

Für falsche Usereingaben sind Exceptions angebracht.

[mkinzler]

Werteabprüfung geht aber immer vor Exception!

[SirThornberry]

Zitat:

Zitat von 3_of_8

Naja, stell dir folgendes vor:

Du hast eine Klasse TWuppdiLoader, die eine Datei vom Typ Wuppdi Laden soll. In der Dateitypspezifikation steht eine CRC32-Prüfsumme. Die stimmt aber nicht mit der Datei überein. Was machst du da? Du könntest jetzt die Funktion beenden und einen Statuscode zurückgeben (z.B. ein Set mit den aufgetretenen Fehlern) oder ein Feld in der Klasse setzen. Aber was ist, wenn der Fehler in irgendeiner Funktion weit verschachtelt auftritt? Dann brauchst du nach jedem Funktionsaufruf sowas wie if FError then exit;

Da ist eine Exception mehr als angemessen, ich würde sogar sagen, für gute Programmierung unausweichlich.

Was spricht aber in dem Fall dagegen ganz oben die Exception abzufangen und in der obersten Funktion dann einen Fehlercode zurück zu geben. Auf diesen kann dann programmseitig auch noch eingegangen werden um ungültige eingaben nicht zu zulassen. Fände ich auf jeden fall besser als dem user die Exceptions um die Ohren zu werfen mit denen er am ende gar nichts anfangen kann.

[shmia]

Es muss ein 3 stufiges Sicherheitsnetz geben:

1.) schon bei den Controls sollte man ungültige Benutzereingaben abfangen und gar nicht erst zulassen
Beispiel: verwendet man einen TDateTimePicker, kann man gar kein ungültiges Datum eingeben; im Gegensatz zu einem TEdit
Wenn man ein Editfeld hat, dass nur eine Zahl aufnehmen soll, kann man z.B. nur Ziffern als Eingabe zulassen oder TMaskEdit verwenden.

2.) Exceptions werden verwendet für alle Fehler, mit denen im Programmablauf gerechnet wird.
Dateien, die nicht geöffnet werden können. Datenbankabfragen, die schiefgehen können, ungültige/fehlende Eingabewerte,
u.s.w.
Dabei sollte man darauf achten, eine möglichst genaue Fehlermeldung zu produzieren.
Von der VCL werden manchmal sehr allgemeine Exceptions generiert (z.B. '' ist kein gültiger Integerwert | ungültige Variantumwandlung)
Diese allgemeinen Exceptions taugen natürlich gar nicht zur Fehlereingrenzung.
Deshalb sollte man regelmäsig Exception abfangen, mit Informationen anreichern und neu auslösen:

Delphi-Quellcode:

// Beispiel
try
  BerechneSteuer(IdKunde);
except
  on E: Exception do
  begin
    // eine informative Meldungen erzeugen
    E.Message := Format('Fehler bei der Steuerberechnung des Kunden %d'#13#10, [IdKunde]) +
      E.Message;  // WICHTIG: die orginale Message anhängen. 
    raise;  // Exception neu auslösen
  end;
end;

3.) der letzte Rettungsanker sind Assertions.
Sie werden verwendet, ob um das Programm vor eigenen Programmierfehlern zu schützen.
Wenn man z.B. eine Funktion hat, die ein Objekt entgegennimmt, sollte man mit Assert sicherstellen,
dass nicht durch einen Programmierfehler ein nil-Zeiger übergeben wird.
Man fängt hier also Fehler ab, die eigentlich niemals auftreten dürften.
Es gilt die Devise: Vertrauen ist gut, Kontrolle ist besser.

Jedes Programm sollte eine Testphase durchlaufen.
Sobald eine Assertion auftritt, muss der Programmierer alles stehen und liegen lassen und die Ursache herausfinden!!

Tritt eine Assertion beim Test oder beim Endbenutzer auf, gibt es zwei Möglichkeiten:
a.) das Programm hat einen Bug
b.) der Programmierer hat eine Assertion verwendet, wo eigentlich eine Exception nötig gewesen wäre

In beiden Fällen ist eine Programmänderung notwendig.
Wenn das Programm gut ausgereift ist, dann darf man die Assertions in den Projektoptionen abschalten
und erhält das ein etwas schnelleres und kleineres Programm.

[phXql]

Shmia sagts.
Rückgabewerte sind veraltet und nicht mehr zu empfehlen, da sie ignoriert werden können.

Zu den Assertions: Nur private Methoden verwenden Assertions zur Prüfung der Argumente. Ist die Methode Public und erwartet sie ein Objekt, dann darf man nicht mit Assertions prüfen, ob es nil ist. Für sowas werden dann Exceptions verwendet.
Bei Assertions gilt: Werden nur verwendet, wenn ich GARANTIEREN kann, dass diese Assertion zutreffen wird, wenn der eigene Code richtig programmiert ist.

[.chicken]

Danke für die ausführliche Erläuterung :)

[rollstuhlfahrer]

noch was zu Asserts:

Zitat:

Zitat von Delphi Hilfe

In der Regel werden Assertions nicht in Programmversionen verwendet, die zur Auslieferung vorgesehen sind. Deshalb wurden Compiler-Direktiven implementiert, mit denen die Generierung des zugehörigen Codes deaktiviert werden kann:

Dies steht unter dem Stichwort Assert

rollstuhlfahrer