Projekt mit
1 €
unterstützen?
So geht das *:


Step 15 - Exceptionhandling.Basiswissen

Try and except (versuche das... und ansonsten tue dies...) wird zur Fehlerbehandlung (Exeptionhandling) verwendet.  Es ist zum Beispiel möglich bei einer Benutzereingabe zu überprüfen, ob es sich tatsächlich um eine Zahl (Integer) handelt:

try                        // versuche....
  i:=StrToInt(Edit1.Text);
except                     // ansonsten tue dies...
  ShowMessage('Error: Bitte geben Sie eine ganze Zahl ein!');
end;

Damit könnte man z.B. den Taschenrechner aus Step 06 so verbessern, dass eine "schöne Fehlermeldung" bei einer fehlerhaften Eingabe erscheint. Der Quelltext des Taschenrechners würde dann so aussehen (für die Addition):

procedure TForm2.Button1Click(Sender: TObject);
var
  zahl1, zahl2 : Integer;
begin
  try                             // versuche
     zahl1:= StrToInt(Edit1.Text);
     zahl2:= StrToInt(Edit2.Text);
     Button1.Caption:= IntToStr(zahl1+zahl2);
  except                          //ansonsten  ...
    ShowMessage('Error: Bitte geben Sie eine ganze Zahl ein!'); // Fehlerausgabe
  end;
end;

Eine weitere Form der Fehlerbehandlung lernen wir später, wenn es darum geht, reservierten Speicher im Fehlerfall wieder freizugeben.

Bei einer sauberen Programmierung geht es alledings nicht unbedingt darum, Fehler wieder aufzufangen, sondern sie besser von vornherein zu vermeiden. Bei unserem Beispiel ginge das durch einen kleinen Algorithmus, der uns hilft, eine Zahl von einem String zu unterscheiden. D.h. Eine Funktion, welche wahr zurückliefert, wenn ein String in eine Zahl umgewandelt werden kann, oder eben falsch, wenn dies nicht gelingt. So kann man sogar genauer sagen woran es liegt, dass die Eingabe nicht als Zahl erkannt wird, was dann sogar noch benutzerfreundlicher ist. Jedoch kommt man nicht immer um die Fehlerbehandlung drumherum, denn es gilt immer den DAU mit einzuplanen - und sollte diese Person das benutzen, muss es nicht nur einfach bedienbar, sondern bombensicher sein ;). Aber okay der eigentliche Grund ist meistens, dass einfach nicht genug Zeit dafür da ist, um wirklich alle Fehlerquellen von Vornherein auszuschließen.

Will man jedoch genauer differenzieren, welche Art von Fehler aufgetreten ist, dann kann man das durch Fehlerklassen machen:

 try
    a := b div c;
  except 
    on EZeroDevide do                          
      ShowMessage('Division durch 0!?!');
	on EIntOverflow do 
      ShowMessage('Integer Überlauf!?!');
	on EIntUnderflow do 
      ShowMessage('Integer Unterlauf!?!');
    else
      ShowMessage('Unbekannter Fehler! b = ' + IntToStr(b) + ' ; c = '+ IntToStr(c) );
  end;
Hierbei wird unterschieden zwischen Division durch 0 und dem Rest an möglichen Fehlern, was in diesem Beispielcode im Grunde nichtsmehr sein kann. Interessant bei dieser Struktur ist allemal, dass vor dem else und davor vor jedem folge-"on" ein Semikolon ist. Die Struktur ist also sehr mit der einer Case vergleichbar. case Errortype of 1 : ....


Da das Kommentarmodul dieser Seite zur Zeit neu überarbeitet werden muss, sendet bitte alle Fragen, Anregungen oder Probleme mit Betreff zu welchem Thema es sich handelt an folgende Mailadresse:


Hinweis:

Dieses Kommentar-Modul teilt seinen Inhalt mit dem gleichnamigen Kapitel im Delphi-Anfängerkurs. Daher kann es vorkommen, dass Fragen zu Lazarus im Anfängerkurs im Delphi-Anfängerkurs und umgekehrt stehen. Wenn ihr euch registriert, werdet ihr aber immer an die richtige Stelle weitergeleitet.
Zu dieser gemeinsamen Nutzung der Datenbank habe ich mich entschlossen, weil die Sprachelemente in Lazarus genauso wie in Delphi genutzt werden können.

www.marco-hetzel.de
www.delphi-lernen.de
www.lazarus-lernen.de

© 2006-2019 by Marco Hetzel , last modified 01.11.2018, 11:28

(* Unterstützung dient der Aufrechthaltung laufender Kosten für dieses Projekt.)