array of byte (dynamisch) schreiben in FileStream

[Flocke]

@Der_Unwissende: über SEH gibt es durchaus geteilte Meinungen, und wir beide scheinen nicht die selbe zu haben

Zitat von Der_Unwissende:

aber um es wirklich sauber zu machen, solltest du immer darauf achten, dass die Erstellung eines FileStreams scheitern kann. Du solltest also mit einer Exception rechnen (z.B. fehlende Lese/Schreibrechte) ...

Das stimmt.

Zitat von Der_Unwissende:

... und das ganze abfangen.

Nein! Wieso auch?

Gerade so einen Tipp interpretieren Anfänger (dazu zähle ich dich nach deinen zahlreichen anspruchsvollen Beiträgen übrigens absolut nicht) oftmals vollkommen falsch. Was dann aus so einem Stück Code wird ist oft (jetzt mal den Ansatz von oben umgedreht -> Einlesen von Daten):

Delphi-Quellcode:

var
  k, BufLen: integer;
  Buffer: array of Byte;
begin
  try
    FS := TFileStream.Create(fn, fmOpenRead or fmShareDenyWrite);
    try
      FS.ReadBuffer(BufLen, SizeOf(BufLen));
      SetLength(Buffer, BufLen);
      FS.ReadBuffer(Buffer[0], BufLen);
    finally
      FS.Free;
    end;
  except
    MesssageDlg('Fehler');
  end;

  // und hier arbeitet man munter lustig weiter, als ob nichts geschehen wäre
  for k := 0 to BufLen - 1 do
  begin
    if Buffer[k] = $55 then ...;
  end;
end;

Was hat man in diesem Fall durch das try...except gewonnen: nichts!

• Die Meldung würde auch bei einer Exception angezeigt, und in dem Fall sogar noch ausführlicher (man wüsste dann immerhin den Grund für den Fehler).
• Ein Fehler löst oft eine ganze Kette von Folgefehler aus, weil die Verarbeitungskette nicht unterbrochen wird (fehlendes Exit oder Raise im Except-Teil, s.o.).
• Man nimmt der aufrufenden Prozedur (falls es eine gibt) die Möglichkeit festzustellen, ob ein Fehler aufgetreten ist.

Lässt man die Exception einfach durchschlagen, dann läuft (zumindest in diesem Beispiel) eigentlich alles besser. Und wenn man das Fenster zu hässlich bzw. zu technisch für die Anwender empfindet, dann kann man doch einfach Application.OnException einen entsprechenden Handler zuweisen.

Persönlich verwende ich try..except fast ausschließlich für die folgenden Fälle:

1. Als erweiterten Ressourcenschutz wo try..finally nicht funktioniert. Beispiel:

Delphi-Quellcode:

Result := TKlasse.Create;
try
  ...
except
  on E: Exception do
  begin
    Result.Free;
    raise;
  end;
end;

2. Für Prüfungen. Beispiel:

Delphi-Quellcode:

try
  ...
  Result := true;
except
  on E: MeineErwarteteExceptionBeiFalschemFormat do
    Result := false;
  else
    raise;
end;

3. Als Schutz vor Fehlern in Fremdkomponenten, die man selbst weder debuggen noch korrigieren kann.

SEH ist aber, wie oben schon geschrieben, ein durchaus kontrovers diskutiertes Thema (siehe u.a. hier) und ich möchte jetzt hier auch keinen `Glaubenskrieg´ lostreten.