Fehler im Programm abfangen...

[badenixe63]

Hallo Leute,

ich habe gerade mein erstes größeres Projekt in Delphi 2006 Explorer fertig.
Dort geht es vor allem darum, dass ich mit einer Indy Komponente Daten von einem Webserver hole, sie verarbeite und wieder anfragen zurück sende. Das ganze funktioniert schon ganz gut, aber es gibt immer wieder Fehlermeldungen weil der Webserver nicht richtig antwortet.

Das reicht von Socket Errors wegen DNS Problemen, bis zu HTTP Errors. Allerdings treten die meiner Meinung nach völlig willkürlich auf und haben eher etwas mit der Erreichbarkeit des Servers, als mit Fehlern im Programm zu tun.

Wie kann ich nun vermeiden, dass solche Fehler zu lästigen Warnmeldungen führen?

Viele Grüße

badenixe63

[fkerber]

Hi!

Es gibt die Möglichkeit solche Stellen, die Fehler werfen könnten, mit try blöcken zu umfassen und entsprechend dann die Fehler zu "fangen" und zu verarbeiten!


Ciao, Frederic

[badenixe63]

ok, ich hab mich mal ein bisschen schlau gelesen.

Also es gibt die Möglichkeit try-exception und try-finally richtig ?

Was kann ich nun nun in so einem Fall tun? Im try-block muss ich ja den request machen... falls da was schief geht, wird direkt der exception block angesprungen. Was kann ich da dann tun ? Muss ich dann noch ein finally dran hängen um die Variablen wieder freizugeben ?

[Matze]

Hallo,

es gibt entweder

Delphi-Quellcode:

try
  // ...
except
  // wird im Fehlerfall ausgeführt
end;

oder

Delphi-Quellcode:

try
  // ...
finally
  // wird immer ausgeführt, ob ein Fehler auftrat oder nicht
  // geeignet um Speicher freizugeben
end;

Was du im Except-Block machst, bleibt dir überlassen. Du könntest dort in eine Log-Datei schreiben, wann was schief gegangen ist, du kannst aber auch einfach eine Meldung ausgeben, dass eine Benutzereingabe fehlerhaft war oder ähnliches. Je nachdem, was du damit bezwecken möchtest.
Den Block leer zu lassen, also den Fehler zu ignorieren, ist jedoch nicht unbedingt empfohlen, da der Anwender wissen sollte, was schief gegangen ist.

Möchtest du beide Blöcke kombinieren, kannst du das so machen:

Delphi-Quellcode:

// Object := TMyObject.Create(...);
try
  // Object.DoSomething;

  // Fehler abfangen
  try
    // Code, indem Fehler auftreten können
  except
    // im Fehlerfall ausführen
  end;
finally
  // FreeAndNil(Object); bzw. Object.Free;
end;

Grüße, Matze

[badenixe63]

danke für die Antwort,

eine Log-Datei ist ne echt gute Idee. Ich möchte den Benutzer nicht mit Fehlermeldungen nerven, weil die Fehler nunmal zwischendurch passieren und der user sowieso nichts dran ändern kann.
Wie soll ich das am besten machen ? Die Datei die ganze Zeit im Schreibmodus offen lassen oder lieber jedes mal wenn ein Fehler auftritt neu öffnen, schreiben und schließen ?

Und noch eine Sache, wie kann ich wirksam verhindern, dass mir Speicherlöcher passieren. Davon habe ich jetzt schon mehrmals gelesen und da das Programm schon für 24/7 gedacht ist, möchte ich nicht, dass dann irgendwann der Computer abstürzt weil kein Speicher mehr da ist.
Ich hab einfach noch nicht ganz kapiert, welche Variablen man an welcher Stelle wie freigeben muss...

[DeddyH]

Installier Dir mal FastMM, damit kommst Du Speicherlecks auf die Spur (im FullDebugMode). Und Objekte sollte man so früh wie möglich freigeben, d.h. sobald sie nicht mehr gebraucht werden. Das am besten in einen try-finally-Block gepackt, dann sollte nicht mehr allzuviel schiefgehen.

Delphi-Quellcode:

Bla := TEinObjekt.Create;
try
  //mach was mit dem Objekt
finally
  Bla.Free;
end;

[Matze]

Hallo,

ich würde die Datei nur dann zum Schreiben öffnen, wenn ein Fehler auftritt.

Normale Variablen musst du nicht freigeben, aber die erzeugten Objekte meistens. Also eine TStringList beispielsweise oder dynamisch erzeugte Komponenten. Letztere müssen nicht unbedingt freigegeben werden, wenn du als Owner beispielsweise das Hauptformular angibst. Denn sobald das durch das Beenden der Anwendung freigegeben wird, werden auch die Komponenten mit diesem Owner freigegeben.

Es schadet aber nichts, auch diese Komponenten freizugeben. An deiner Stelle würde ich alles, was du über

x := TSomething.Create; erzeugst, so schnell wie möglich auch wieder freigeben, d.h. sobald du nicht mehr darauf zugreifen musst.

Grüße

[badenixe63]

was ist, wenn ich damit nur in einer Prozedur arbeite ?

also

Delphi-Quellcode:

procedure TuWas;
var
myObject:TObject;
begin
  myObject := TObject.Create();
  //mach was mit myObject
end;

diese Prozedur wird von einem Timer immer wieder aufgerufen. Eigentlich müssten alle lokalen Variablen und Objekte der Prozedur doch nachdem sie ausgeführt wurde gelöscht werden und beim nächsten Aufruf neu erstellt werden oder ?

--> ich hab versucht FastMM zu kriegen, aber da gibts nur quellcode von SourceForge. Muss ich mir das selbst kompilieren oder gibts da was fertiges ?

[DeddyH]

Der Quellcode ist schon das, was Du brauchst. Dann musst Du den Pfad zu FastMM dem Bibliothekspfad von Delphi hinzufügen und als erste im Projekt eingebundene Unit FastMM4 eintragen. Und zum Freigeben: wenn es so wäre wie Du meinst, würde so etwas ja nicht funktionieren.

Delphi-Quellcode:

var EinObjekt: TEinObjekt;
begin
  EinObjekt := TEinObjekt.Create; //Objekt erzeugen
  ListBoxBla.Items.AddObject('Wuppdi',EinObjekt); //und den Objects einer ListBox hinzufügen
end;

Jeder spätere Zugriff auf die Objekte würde ja dann zur AV führen.

[badenixe63]

Zitat von DeddyH:

Jeder spätere Zugriff auf die Objekte würde ja dann zur AV führen.

und warum passiert das nur bei TObjekten und nicht bei normalen Variablen? Die könnte ich doch auch in eine ListBox übernehmen oder ?