>Gerardo Richarte <gera at core-sdi.com> wrote:
>>     Sometimes I have a problem... When some Morph is stepping and
>> suddenly an error pops up from its #step method, I can stop this
>> happen, soI need to quit squeak without saving, what I dont like!
>>     I can understand why this happens, and that its perfectly normal
>> (if there is such an error), but Id like to have a way of stopping
>> this, or better, to make the morph stop stepping if there is an error in
>> its #step method.
>>     Any idea out there?
>> 
>>     Unsolvable Bye!
>>     Richie++

lex at cc.gatech.edu replied...
>I've noticed you can still use the root menu to jump to another project.  Then you can do a few "allInstance"'s and "delet" the offending morph, before heading back in.
>
>I agree, though, this is a common nuisance....
>
>Maybe the world should simply stop stepping when a debugger pops up?

That's one approach, but then the inspectors that you might want to use won't update.

I have two solutions in mind, but they're both a little ways out.

1.  Add some intelligence to the debugger, so that if it sees that a morph was doing drawOn:, fullDrawOn: or step, then it wraps it in another morph that looks like a radiation warning.  That wrapping morph has a couple of menu commands that will restore its place in the morphic structure and the list of stepping morphs after (you think) you've fixed the problem.

2.  The debugger already detects recursive errors.  This is just as much of a problem in MVC as in Morphic.  In MVC it bails out to a primitive stack dump, and the chances are slim that you can proceed.  This happens if you make an error editing something used by the debugger like text or window or pane code.

In morphic, it's not usually a recursive error, but a repeated call to step or display before the error is fixed.  One possibility is to call display and step once from the debugger and thus force this to appear as a recursive error.  Then at least we have recursive errors in both the MVC and Morphic flavors of disaster.

Now all we need is a better answer to recursive errors.  There are two main causes:  bad code and bad stuff in the world.  My proposal is (as part of the forthcoming history mechanism) to establish instant code change retraction at project boundaries.  Then when all else fails (ie when you have a recursive error), you should be able to perform a code change retraction and jump to another project, and put up the debugger THERE.  The code should be OK, and the debugger would be the only thing on the screen.

This is in many ways equivalent to debugging one image from another, except it's all in one simple (clever) Squeak.  I'm hoping we can try this out early next year.

Never say Unsolvable

	- Dan