Prüfen, ob eine Adresse auf eine Procedure zeigt

[NicTheQuick]

Mit Try und Catch kann man auftretende Exceptions einfach nur sauber verarbeiten. Ohne das wird eine Exception durch den Call-Stacks durchgereicht und kommt schließlich beim Betriebssystem an, das den Prozess gestartet hat.
Oder was wolltest du wissen?

[mestnyi]

Code: Alles auswählen

CompilerIf Defined(ProcedureName, #PB_Procedure)
  Debug "#True"
CompilerEndIf

[RSBasic]

@mestnyi
Du kannst da aber keine Speicheradresse übergeben, sondern ausschließlich den Namen der Prozedur.

[GPI]

das mit den Macro ist vielleicht keine dumme Idee.

Code: Alles auswählen

Macro SetCallback(ProcedureName)
CompilerIf not Defined(ProcedureName, #PB_Procedure)
  compilererror "not a procedure"
CompilerEndIf
*callbackpointer=@ProcedureName
...
EndMacro

@Nic
Mit der PC-Architektur kenn ich mich halt nicht so aus.
Es kommt auch drauf an, wie der Compiler das ganze löst.
Ich kann mich bspw. daran erinnern, das QBasic (VB glaub ich auch) so dumme angewohnheiten hat, wenn bspw. eine Datei nicht per Open geöffnet werden konnte, das Programm mit einer Fehlermeldung abbricht.
Das war aber eine reine Compilergeschichte.

Wie gesagt, PC kenn ich da nicht so, beim Atari ST (68000 Processor) war es so, das wenn man da durch Null teil, eine CPU-Ausnahmesituation ist, wo die CPU entsprechend reagiert (springt auf eine vorher definierte Stelle in Speicher und führt den Code da aus. Beim Atari ST wurden dann bomben auf den Bildschirm gemalt

Wenn ich mir das da durchlese:
http://www.cplusplus.com/doc/tutorial/exceptions/
Das ist imo etwas anderes, hat mit Fehlern wie ungültiger Programmcode oder durch Null teilen nur bedingt zu tun bzw. mit der OnError-Bibliothek.
Der Compiler sorgt halt dafür, wenn die Throw()-Anweisung kommt, das alles aufgeräumt wird und bei "Catch" weitergemacht wird. Es muss also nicht dafür gesorgt werden, das die "CPU" abstürzt, damit es weiter bei Catch geht.
Die Funktionsweise ähnelt "onError", ist aber imo was anderes.

Ich würde sagen, der Compiler merkt sich bei Try() wo der stack gerade ist (damit man eventuelle Unterprogrammaufrufe aufräumen entfernen), vermerkt irgendwo in einer versteckten Variable, das gerade ein Try läuft und wo der dazugehörige Catch ist.
Wenn er auf ein Throw stößt, setzt er den Stack zurück auf die gemerkte stelle und macht bei catch weiter. Problematisch dürften Objekte sein. Da die aber immer initalisiert werden müssen, muss halt die Init-Routine des Compilers überprüfen, ob gerade ein Try läuft und sich sämtlich lokal erstellten Objekte merken. Sollte imo kein Thema sein. Bei Throw werden dann die gesamten objekte vernichtet und es sollte alles aufgeräumt sein.

Ich würde das in Purebasic das so lösen, das ich den Teil in "try"-Pfad in einen Thread starte und in Hauptprogramm warte, bis Try fertig ist. Falls was in Thread nicht passt, verändert er mit "throw()" eine globale Variable killt den eigenen thread. Theoretisch könnte das Hauptprogramm entsprechend reagieren. Ein Thread hat doch seinen eigenen Stack etc? Dann würde das Killen den "Müll" beseitigen, der entsteht, wenn man bspw. in einer Procedure das ganze auslöst.