Zitat von
Sherlock:
Ich gebe hier mal ein Extrembeispiel (dafür wie man es nicht machen sollte), einer meiner Kollegen hat vor Jahren mal in die
dpr ein try...except um alles gepackt.
Sherlock
Da ist dein Kollege nicht alleine. Windows hat sogar einen Unhandled-Exceptionhandler vorgesehen
Zum Thema:
ein einfacher try-Except oder try-finally-Block bremst dein Programm nicht aus. Erst, wenn wirklich eine
Exception auftritt, geht es los. Dies apssiert aber auch, wenn kein Except-Block existiert. Bei letzterem stürzt der Thread oder das Programm ab.
Um jede Ereignisbehandlung hat die
VCL einen try-Except-Block gelegt.
was passiert nun bei try:
Es gibt für jeden Thread einen Thread-Context. Der befindet sich im Segement fs. Und dort an erster Stelle. Wenn irgendwo eine
Exception auftritt, schaut windows an die Adresse fs:[0]. Und dort steht ein Pointer auf einen Record. Der Record besteht aus 3 Teilen und wird beim Befehl try angelegt:
-Register EBP
-Adresse des Except (finally) Blocks (man sagt auch Adresse des "save Place")
-Adresse des des bisherigen ExceptionRecords (es wird also eine Liste der Records aufgebaut
So, jetzt kommt ein Satz Halbwissen:
Der Record muss zwingend auf dem Stack liegen, dadurch ist auch klar, welchen Wert ESP zum Zeitpunkt des try hatte.
Was passiert also bei einem try genau? Es werden 3 Befehle ausgeführt:
Delphi-Quellcode:
asm
push ebp
push @Exceptblock
push fs:[0]
mov fs:[0], esp
end;
Von Prozessorauslastung kann dabei keine Rede sein. Denn jetzt kommt ganz normal der Code hinter dem try, egal ob diese 4 Befehle davor stehen.
Und hinterher (wenn keine
Exception auftrat) muss natürlich der Stack wieder aufgeräumt werden und der Wert an fs:[0] zurückgesetzt:
Delphi-Quellcode:
asm
//Beispiel
pop fs:[0]
pop edx
pop edx
end;
Fertig.
Im Übrigen setzt Delphi um jede Funktion, die dynamische Arrays oder strings oder Variants verwendet, einen try-finally Block