Stepping when you shouldn't hangs Pharo

[LisaAlmarode]

Using the testDebug method (see issue #78), I was able to hang pharo quite hard (this is on windows).

1. accept ChangesFinder testDebug
2. see first halt, use green-arrow continue.
3. see second halt, do another green-arrow continue. This is going to be an error in that select is expecting a boolean, but halt is not returning a boolean.
4. in the frame inspector (rightmost pane), select the "step over" bottom icon. This is certainly not a reasonable action... 5. see a sparkle broken promise error. Attempt to close this... clicked around in the debugger panes and closed explorer. Then, can't open a new explorer nor disconnect the session and pharo needed a hard kill.

[martinmcclure]

I think the root cause here is that you shouldn't be able to step or proceed after a non-resumable error. Kurt and I discussed this the other day, but I haven't implemented it yet, so it's good to have an issue for it.

[martinmcclure]

ChangesFinder testDebug appears to be this code:

testDebug
    | keys badKeys |
    keys := {'cat'.
    'draw'.
    'apple'}.
    self halt.
    badKeys := Array new.
    badKeys
        addAll:
            (keys
                select: [ :ea | 
                    ea trimSeparators size ~= ea size.
                    self halt ]).
    ^ badKeys printString

[dalehenrich]

As I mention here ... topaz allows multiple continues on a non-resumable error so i don't imagine that the root cause is the continue (at least as far as the bottom-level process continue code) ... the implication is that the hang is coming a bit higher up the stack ... all depends upon how deep the root is expected to go :)

[martinmcclure]

This example now appears to be debuggable. Due to the loop in _uncontinuableError you can, if you want to, pile up errors on the stack. But you can then terminate the process and all is OK.