Bitte Warning erklären

[Shark99]

Bei dem Code:

Delphi-Quellcode:

var
  list: TStringList;
begin

  try
    list := TStringList.Create;

bekomme ich diese Warnung:

[Warning] LanguageHandlerUnit.pas(126): Variable 'list' might not have been initialized

Kann mir bitte erklären wieso ich vor try list := nil zuweisen muss?

[himitsu]

Das muß davor.

Delphi-Quellcode:

var
  list: TStringList;
begin
  list := TStringList.Create;
  try
    ...
  finally
    list.Free;
  end;

Delphi prüft, ob das list im finally auf jedenfall initialisiert wurde und das trifft nur zu, wenn es vor'm Try passiert.

- Speicher reservieren (oder was auch immer)
- direkt danach das TRY
- dann kann sonstwas zwischen try-finally stehn
- und dann im finally als Erstes das .Free

[s.h.a.r.k]

Man kann hier evtl. auch noch erwähnen, dass wenn im Konstruktor eine Exception auftritt, das Objekt nicht erzeugt wird. Daher wäre es falsch, das list := TStringList.Create; hier nach dem try einzufügen -- warum sollte klar sein.

[stahli]

Was wäre aber, wenn man zwei Objekte hat und die Erzeugung des ersten (warum auch immer) fehl schlägt?

Delphi-Quellcode:

var
  list1: TStringList;
  list2: TStringList;
begin
  list1 := TStringList.Create; 
  // vorige Zeile oder hier schlägt etwas fehl...
  list2 := TStringList.Create;
  try
    ...
  finally
    list2.Free;
  end;

Hier müsste man wohl jede Menge try-Blöcke verschachteln?

Auch wenn ich mich unbeliebt mache, ich setze solche Schutzblöcke eigentlich selten ein. Meist nur, wenn ein E/A-Fehler passieren kann und dieser intern ausgeglichen werden soll.
Ansonsten achte ich lieber darauf, alle negativen Voraussetzungen Divisor = 0, Objekt = nil etc. vorab abzuprüfen.

Ich gehe schon mal in Deckung ...

[DeddyH]

Entweder verschachteln oder die folgenden initial mit nil belegen, bevor das erste Objekt erzeugt wird.

[edit] Achja, Exception-Handling ist ja nicht dazu gedacht, mögliche Fehlerquellen nicht im Vorfeld ausschließen zu müssen, sondern eher dazu, auf Fehler reagieren zu können, die nicht vorhersehbar sind (Hardwaredefekt, volle Festplatte oder sowas). [/edit]

[himitsu]

Zitat von stahli:

Hier müsste man wohl jede Menge try-Blöcke verschachteln?

Jupp
http://www.delphipraxis.net/155747-t...ml#post1060288

[s.h.a.r.k]

Auch wenn es unschön aussieht, wäre es für die eigene Anwendung auch gesünder. Kann ja evtl. auch vorkommen, dass andere deinen Code nutzen und daher wäre es auch sehr ratsam alles so robust wie möglich zu bauen. Selbst wenn es nur "interne" Klassen sind, die also innerhalb einer eigenen Komponente genutzt werden, baue ich diese so auf, dass interne Fehler durch passende Exceptions aufgedeckt werden, obwohl ich eigentlich weiß, dass ich den Code richtig nutze. Sicher ist sicher (und insgesamt, dann auch sauber programmiert)

-- EDIT: Wuhu, Beitragscounter = Geburtsjahr -- gerade Zahlen kann jeder feiern

[himitsu]

Soll heißen, selbst wann man keine Exceptions behandeln will, sollte man dennoch die Resourcen absichern.

Exceptionbehandlung ala Try-Except ist ein Kann ... muß aber nicht
Ein Resourcenschutzblock ala Try-Finally sollte aber dennoch rein.

[stahli]

Ich will jetzt keine große Grundsatzdiskussion lostreten, aber im obigen Beispiel und ähnlich überschaubaren Programmteilen würde ich erst mal nicht mit Problemen rechnen.
Mir ist aber schon öfters aufgefallen, dass die try-Blöcke auch in trivialen Zusammenhängen eingesetzt werden. Eine Lösung das Problems bietet die doch aber auch nicht...
Ok, eine erzeugte Komponente wird wieder freigegeben, aber das ist ja eigentlich das geringste Problem. Die Prozedur o.ä. wurde trotzdem nicht korrekt durchgeführt.
Insofern ist der Systemzustand mit oder ohne try-Behandlung relativ inkonsistent.

Anders sieht es z.B. bei Dateizugriffen o.ä. aus (oder an Stellen, die immer "erwartet" problematisch verlaufen können und dementsprechend eine alternative Behandlung benötigen). Hier kann ich Fehler abfangen und explizit darauf eingehen.

Der Sinn von try-Blöcken zur Freigabe von Komponenten hat sich mir noch nie wirklich erschlossen (auch wenn ich es häufig in fremden Quellen sehe).

Zur Entschärfung des Konfliktpotenzials gleich mal einen Glückwunsch an s.h.a.r.k hinterher! Himitsu kann ich gerade nichts passendes anbieten

[Bernerbaer]

Für mich ist folgendes Konstrukt eigentlich der übersichtlichste und sauberste Weg um das Bsp von sahli umzusetzen.

Delphi-Quellcode:

var
  list1: TStringList;
  list2: TStringList;
begin
  list1:=nil;
  list2:=nil;
  try
    list1 := TStringList.Create; 
    list2 := TStringList.Create;
  
    ...
  finally
    list1.free;
    list2.Free;
  end;