PureBoard

ts-soft hat geschrieben:

NicTheQuick hat geschrieben:Ja, ein Try-Catch wäre Bombe. Ich glaube ganz früher zu PB V2.x Zeiten hatte Rings mal eine Try-Catch-Funktion implementiert. Oder war es Danilo? Ich weiß nicht mehr genau. Das hätte ich jedenfalls auch gerne wieder. Alternativ kann man hier nur noch mit OnError arbeiten.

Die Try-Catch Lib war von Remi Meyer, in ASM geschrieben und die funktionierte wirklich gut. Es gibt noch weitere Try-Catch Routinen im engl. Forum, aber ich denke die Version von Danilo ist noch am ausgereiftesten, funktioniert leider nicht immer:
http://www.purebasic.fr/english/viewtop ... 39#p380239

NicTheQuick hat geschrieben:Wenn mir jetzt noch jemand beibringt, wie ich das mit anonymen Labels machen kann, [...]

Macro Try
   OnErrorGoto(?label#MacroExpandedCount)
   If #True
EndMacro
Macro Catch
   Else
   label#MacroExpandedCount:
EndMacro
Macro EndTry
   EndIf
   OnErrorDefault()
EndMacro

Procedure a()
EndProcedure
Procedure b(a.i)
EndProcedure
Procedure c(a.i, b.s)
EndProcedure

q.q = 123457698123

Try
   CallFunctionFast(@a())
   Debug "a() hat funktioniert."
Catch
   Debug "a(): " + ErrorMessage() + "(@" + Str(ErrorAddress()) + ")"
EndTry

Try
   CallFunctionFast(@b(), 1)
   Debug "b(1) hat funktioniert."
Catch
   Debug "b(1): " + ErrorMessage() + "(@" + Str(ErrorAddress()) + ")"
EndTry

Try
   CallFunctionFast(@c(), 1, 2)
   Debug "c(1, 2) hat funktioniert."
Catch
   Debug "c(1, 2): " + ErrorMessage() + "(@" + Str(ErrorAddress()) + ")"
EndTry
   
Try
   CallFunctionFast(@q)
   Debug "q hat funktioniert."
Catch
   Debug "q: " + ErrorMessage() + "(@" + Str(ErrorAddress()) + ")"
EndTry

RSBasic hat geschrieben:Jemand aus diesem Forum hat mal nach einer Try-Catch-Funktion gefragt. Soweit ich weiß gab es auch eine Lösung, die gepostet wurde.
Könnte man nicht einfach mit Hilfe der eigenen Try-Funktion überprüfen, ob auf eine ungültige Speicheradresse zugegriffen wird?
Wenn beim Aufruf von CallFunctionFast() ein IMA-Fehler auftritt, dann weiß man, dass die übergebene Speicheradresse entweder nicht vorhanden ist oder dass der Pointer nicht auf eine Prozedur zeigt.
Leider kann ich den Thread nicht mehr finden und kann deshalb den Code nicht testen und hier verlinken. Vielleicht findet ihr den Thread.

NicTheQuick hat geschrieben:Man kann Try-Catch schon simulieren mit OnError():

GPI hat geschrieben:Imo sollte man nach Möglichkeit immer ohne Try/Catch auskommen. In der Regel kann man ja abfragen, was man macht - bspw. ob durch Null geteilt wird.

Macro Try
   OnErrorGoto(?label#MacroExpandedCount)
   If #True
EndMacro
Macro Catch
   Else
   label#MacroExpandedCount:
EndMacro
Macro EndTry
   EndIf
   OnErrorDefault()
EndMacro

Try
CallFunctionFast(50)
Catch
MessageRequester("Fehler", "Funktion kann nicht aufgerufen werden!")
EndTry

Sicro hat geschrieben:

GPI hat geschrieben:Imo sollte man nach Möglichkeit immer ohne Try/Catch auskommen. In der Regel kann man ja abfragen, was man macht - bspw. ob durch Null geteilt wird.

Als Programmierer sollte man eigentlich alle möglichen Fehler voraussehen, ja, aber wie wir Menschen nun mal sind, vergessen wir manchmal eine Fehlerbehandlung oder bauen sie nicht ein, weil wir gar nicht wissen, dass so ein Fehler auftreten kann. Von daher sind Try-Catch-Blocks kein schlechter Programmierstil, weil sie in der Regel alle Fehler abdecken.

Da wir bei einer Procedure-Adresse nur auf "ungleich 0" und "gleich 0" prüfen können, ist Try-Catch hier aktuell die einzigste Lösung.
Ich würde aber so ein Aufwand nicht machen. Wenn der Fremd-Entwickler sich nicht an die Doku hält und einen Unsinn als Callback-Adresse angibt, knallt es halt.

Hinweis: Der Program-Stack wird nicht angepasst, bevor zu dieser Sprungmarke gesprungen wird. Daher sollte auf lokale Variablen nicht zugegriffen werden, da sie möglicherweise nicht mehr erreichbar sind. Es ist auch nicht sicher, die normale Programmausführung nach einem Fehler fortzusetzen, da Dinge wie die Return-Adresse einer Prozedur falsch sein können, wenn der Stack nicht länger korrekt ist. Die beste Vorgehensweise ist, einfach Informationen über den Fehler zu erfassen und anzuzeigen und dann das Programm zu beenden.

ts-soft hat geschrieben:Es gibt schon sinnvolle Anwendungen für Try/Catch, z.B. eine unbekannte Datei, die man parst und die auf einmal unvorhersehbare Ergebnisse liefert, die zu einem IMA führen würden. Da wäre ein Try/Catch ganz praktisch, weil man kann die Datei nach dem unvorhersebaren Ergebnis, zu ende Parsen. Z.B. Object-/Libdateien wären Kandidaten dafür.