@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.