also wenn dein Programm nach der
Exception noch 'ne Weile ordentlich weiterlaufen soll, dann dort, wo du etwas schützen mußt >>> Resourcenschutzblock
Delphi-Quellcode:
// hier Speicher reservieren / etwas sperren oder sonstwas,
// was auf jeden Fall rückgängig gemacht werden muß
Lock; oder X:=GetMem; oder Y:=Z.Create;
try
//hier was machen
finally
// und hier den Speicher freigeben oder die Sperre aufheben
Unlock; oder FreeMem(X); oder Y.Free;
end;
oder wenn du selber auf die
Exception reagieren willt, um stattdessen etwas Alternatives zu machen
Delphi-Quellcode:
try
// mach was
except
// mach stattdessen was Anderes
end;
Es ist garnicht möglich wirklich auf alles zu reagieren, also besinn dich nur auf das "Nötigste", dann bleibt dein Code auch übersichtlicher.
in nochmalen
VCL-Anwendungen (nicht in einer Konsolenanwendung) ist eh nahezu jeder Prozeduraufruf seitens der
VCL (also z.B. Ereignisprozeduren) mit einem Try-Except abgesichert, so daß nicht gleich das ganze Programm verreckt, wenn mal was passiert.
PS: in meinem aktuellen Projekt (
himXML) fang ich absichtlich fast garkeine Exceptions ab (und wenn, dann wandle ich die meißt in eigene Exceptions um), leite alles nach Außen hin weiter und erzeuge notfalls sogar selber Exceptions.
Ich sorge meist nur mit einem Try-Finally daß möglichst keine Speicherlecks entstehen. (kannst dich da gern mal umsehen)
So kann man im aufrufendem Code besser reagieren und man erfährt auch was und wo es geknallt hat ... denn wenn es knallt, dann hat das 'nen Grund und den gilt es zu finden und zu beheben, anstatt alles unter den Teppisch zu kehren.
PSS: meinen
FileSplitter hab ich damals ganz ohne Try-Except/Finally programmiert, denn diese sing garnicht immer nötig, wenn man die Fehler vorher abfängt (also bevor es knallt) und man weiß was man tut und was passieren könnte bzw. was nicht passiert.