abort use

Erik Friesen

I am wanting to abort all calls up to a certain point when my device connects to a usb port. In the below method for example, if I do an abort trap before each call like , \countboard , will it stop at that or continue?

With no abort trap where would I end up?

Pub Mainmenu |a
selection:=1

repeat
  text.out(1)
  limit:=5
  hilite(1)
  text.str(string(size,2,1,"Count Board   "))'spaces 14
  hilite(2)
  text.strsp(14,string($d1,"File"))
  hilite(3)
  text.str(string($d2,"Easy Estimate "))
  hilite(4)
  text.strsp(14,string($d3,"Tools"))
  text.out($d4)
  if selection==5
    text.out($c2)
    text.str(string("Rename "))
    text.out($c2)
  text.filestr(@filename)
  text.out($c1)
  if selection<>5 
    text.str(string(  " Open  "))
  if key[noparse][[/noparse]Ksel]==1    
    repeat until key[noparse][[/noparse]Ksel]==0
    case selection
      1:countboard
      2:Filemenu
      3:estimenu
      4:toolmenu
      5:renamefile("f",@filename)
  testoff

hippy

With no abort traps, any 'abort' will stop the Spin program entirely ( but leave other Spin methods launched in other Cogs running ). An 'abort' simply returns by dropping through calls until it finds the latest call which had an abort trap, then continue with the statement executed after it.

With '\countboard' an 'abort' would return to the statement executed after it. In this case the program should continue at 'testoff'.

There's a special case with "\TrapThisCall( MethodFunction(10) )" whereby an abort in 'MethodFunction()' doesn't continue at the statement after it but drops out of the method which contains it.

Best thing I found was to write some test programs to get a feel for how abort and abort trapping works using some 'print statements' to show execution progress and path.

Phil Pilgrim (PhiPi)

Hippy,

Is that (abort trapping) what the "MARK" bytecode that I noticed in one of your posts gets used for?

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

rokicki

Just to make sure I'm clear:

\TrapThisCall(MethodFunction(10)), where MethodFunction aborts, behaves identically to

TrapThisCall(MethodFunction(10)), correct?

That is, the trap catching is not set up until the arguments are evaluated and TrapThisCall
is actually invoked?

If the behavior differs from this, that's unusual and surprising.

hippy

@ Phil : No, MARK does some twiddling with the stack to keep a return value after removing a stack frame when calling a Method to produce a parameter for use ( or somthing like that. ) Chip calls that "run" in the interpreter.

The Trap handling is done by what I call FRAME and Chip called "drop anchor". There are four options there as two bits, keep/discard return result, trap/don't. These are executed sometime previous to the method CALL or cross-object method-call CALLOBJ.

@ rokicki : Yes, that's how I saw it working.

I felt this behaviour was wrong / unexpected because I took the trap to mean, "check this call worked, and continue regardless", so to me an abort in MethodCall should be no different to an abort in TrapThisCall.