Bestimmte Dateien und Verzeichnise in einem Stammverzeichnis löschen

[DeddyH]

Brauche ich nicht, das erledigt IncludeTrailingPathDelimiter von ganz alleine ;). Und ich habe ja gar nicht gegiftet, sondern nur darauf hingewiesen, dass da potentielle Fehlerquellen im Code stecken. Wenn Popov da gleich ausrastet, ist das sein Problem.

[p80286]

Zitat:

Zitat von DeddyH (Beitrag 1156764)

Brauche ich nicht, das erledigt IncludeTrailingPathDelimiter von ganz alleine ;).

Gut zu wissen! Danke

Gruß
K-H

[Popov]

Das hat nichts mit ausrasten zu tun sondern mit einer von oben herab Art. Es geht auch freundlicher.

Was deine Nullprüfung angeht, so hast du den wichtigsten Satz von mir überlesen: "Da ich zufällig ein Projekt offen habe in dem sich diese Funktion befindet". In diesem Fall ist es eine individuelle Funktion, von allem Balast befreit. Als Pfad kommt der Programmpfad plus Unterordner. Also kein Nullpfad da ein Programmpfad existiert. Für die Aufgabe für die sie gedacht ist funktioniert die Funktion fehlerfrei. Ich habe nichts gegen eine Verbesserung, aber wenn Kritik kommt, dann solte man zuerst den Hintergrund erfragen. Dann kann man.

Dann zum try finally. Zwei Punkte: auch hier werde ich nicht schon wieder eine Diskussion darüber führen will, ob es nötig ist oder nicht. Ich bin der Meinung nein. Wozu? Ist schon paar Jahre her, aber ich bin der Meinung es ausdiskutiert zu haben. Und zweitens:

Delphi-Quellcode:

  if FindFirst(Path + '*' + Ext, Attrib, Search) = 0 then
    try
      repeat
        List.Add(Path + Search.Name);
      until FindNext(Search) <> 0;
    finally
      FindClose(Search);
    end;

So wie es ist wird FindClose bei einem leeren Ordner nicht ausgeführt. Oder irre ich mich da?

[DeddyH]

Du irrst nicht. In dem Falle ist das aber auch gar nicht nötig. Übrigens sollte man auch in individuellen Projekten immer mögliche Fehlerquellen ausschließen, das hat mit privatem Gebrauch oder dergleichen nichts zu tun. Ich denke da an einen Satz, den ich von einem Entwickler einmal gehört habe "Das ist kein Bug, es tritt ja nur in ganz speziellen Situationen auf.". Was soll man dazu noch sagen?

[Popov]

Nicht nur in diesem Fall. FindFirst und FindNext liefern bereits Fehlercodes, d.h. deren Fehler wurden bereits abgefangen. Sie noch mal in ein Schutzblock stecken ist doppeltgemoppelt.

[Luckie]

Nur dass WinAPI Funktionen keine Delphi Exceptions auslösen.

[Popov]

Es geht nicht um Exceptions. if FindFirst(...) = 0 then kein Fehler else Fehler.

[Luckie]

Ich sehe in deinem Code aber einen Except-Finally-Block. Oder wirft die VCL Kapselung eine Exception?

[Popov]

In welchem?

[DeddyH]

Zitat:

SysUtils.FindClose
Gibt den mit FindFirst zugewiesenen Speicher frei.

So, und das passiert eben nicht, wenn z.B. beim "List.Add" eine Exception auftritt (Liste ist nil oder was weiß ich), wenn man auf den try-finally-Block verzichtet. Ist FindFirst <> 0, wird ja gar kein Speicher belegt, da ist FindClose also überflüssig (schadet aber auch nicht). Im Übrigen halte ich mich aus einer weiteren Diskussion ab sofort heraus, da sie in meinen Augen sinnlos ist.