|
|
I am not sure if someone already noticed this but when debugging
something like on a workspace:
[2/0] on:Error
do:[:ex| 'I would like to step here! ' printOn: Transcript.
Transcript cr;
flush]
You never get to the outer niladicBlock. My understanding of the
SkipTable is that selectors with attribute 0 will be ignored by the
dubugger but subsequent messages will be caught by the debugger. I
don't have a good idea how to solve this problem but I would be open to
try any ideas about this.
I also noticed that the debugger will step in the returning frame of
these methods, because the debugger does not check when returning from
one call if the calling frame was skipped. For example, if you debug
the following on a workspace:
[2 factorial] on:Error
do:[:ex| 'I would like to step here! ' printOn: Transcript.
Transcript cr;
flush]
You will be able to step #factorial and we you finish with the block
the next thing in the stack is #markAndTry, the frame that was created
from your workspace is the seventh frame from the top in the middle is
all the stuff that you never saw about #on:do:, which was probably a
good thing. I don't think will be hard to make the debugger consistent
in this matter. One solution, I tried it, is to make the debugger skip
a returning frame of a selector that is in the SkipTable. The other
solution is to do something similar but at the process level.
Federico
|
Locked
