"**System error handling failed**"

Dan Ingalls Dan.Ingalls at disney.com
Wed Apr 26 21:41:57 UTC 2000


>jchludzinski at grci.com wrote:
>> Sometimes when executing some of my code, the upper left corner of the Squeak
>> main window shows a stack dump (in a white square) with the message "**System
>> error handling failed**" at the top of the square and "**Type any character to
>> continue**".
>> 
>> Should I expect this?
>> Will this (to some extent) disappear in 2.8?

Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> responded...
>This happens when something goes wrong inside Morphic. The odd placement is
>just because Morphic has run amok and so can't be used for error display.

This has nothing to do with morphic -- the exact same thing happens in MVC.  What it has to do with is that things are bad enough that the system is unable to put up an error notification.  The debugger detects this by noticing that it has been reentered before completing the first notification.  It's a bad scene by all accounts.  It could be more informative, and it could leave the screen looking less trashed, but the fact is you're probably dead meat at that point.  The ugliness of the display is just because of wanting to get the information onto the display with a bare minimum of code -- the more code, the less likely it is to present the info without hitting another error.

Hopefully this will (to some extent) disappear in 2.8.

It is already true that if you are working with isolated changes, there is a high probability of recovering from such errors.  Isolated changes are new, and not perfect yet, but they work within their current limitations, and I have already saved myself this way once (see self-serving testimonial below).

Meantime, if someone wants to make the old emergency debugger (which is still needed when not using isolated changes) a little bit prettier and a little bit more informative, without adding much code, we would certainly consider inclusion of the changes.

	- Dan
-------------------------
To: SqueakCentral
Subject: First involuntary use of modular error recovery
Date: April 22, 2000

Folks -
I've been using an isolated project for my syntax work, both to test stuff out, and because sometimes I don't want all those changes in my regular work.

So there I was cruising along, updating the code for <String>numArgs to deal with initial and final keywords.  Suddenly, Bam-o I'm in my outer project, reading the you-would-have-been-dead-meat message in a Squeak error window.  Sure enough, my change broke a perform used in window managment which would have crashed my Squeak if I had not been in an isolated project.

I just browsed to the changeSet from the outer project, removed the offending change, and *restarted* a couple of frames above in the debug window.  This took me back into the syntax project, reasserted all but the deadly change, and left me right where I had been with no lost motion.  Just had to crow.

...and if anyone is curious, here is the text of the "dead meat" message...
----------------------
isolationRecoveryAdvice
	"Return a notifier message string to be presented in case of recovery from recursive error by revoking the changes in an isolation layer.  This surely ranks as one of Squeak's longer help messages."

	^ 'Warning! You have encountered a recursive eror situation.

Don''t panic, but do read the following advice.  If you were just fooling around, the simplest thing to do is to quit and NOT save, and restart Squeak.  If you care about recovery, then read on...

In the process of diagnosing one error, further errors occurred, making it impossible to give you a debugger to work with.  Squeak has jumped to an outer project where many of the objects and code changes that might have caused this problem are not involved in normal operation.  If you are looking at this window, chances are that this first level of recovery was successful.  If there are changes you care a lot about, try to save them now.  Then, hopefully, from the state in this debugger, you can determine what the problem was and fix it.  Do not save this image until you are confident of its recovery.

You are no longer in the world that is damaged.  The two most likely causes of recursive errors are malformed objects (for instance a corrupt value encountered in any display of the desktop) and recurring code errors (such as a change that causes errors in any attempt to display the desktop).

In the case of malformed objects, you can attempt to repair them by altering various bindings in the corrupted environment.  Open this debugger and examine the state of the objects closest to the error.

In the case of code errors, note that you are no longer in a world where the erroneous code is in effect.  The only simple option available is for you to browse to the changeSet for the project in distress, and remove one or more of the changes (later it will be possible to edit the code remotely from here).

If you feel you have repaired the problem, then you may proceed from this debugger.  This will put you back in the project that failed with the changes that failed for another try.  Note that the debugger from which you are proceeding is the second one that occurred;  you will likely find the first one waiting for you when you reenter the failed project!  Also note that if your error occurred while displaying a morph, it may now be flagged as undisplayable (red with yellow cross);  if so, use the morph debug menu to choose ''start drawing again''.

If you have not repaired the problem, you should close this debugger and delete the failed project after retrieving whatever may be of value in it.

Good luck.

	- The Squeak Fairy Godmother

PS:  If you feel you need the help of a quantum mechanic, do NOT close this window.  Instead, the best thing to do (after saving anything that seems safe to save) would be to use the ''save as...'' command in the world menu, and give it a new image name, such as OOPS.  There is a good chance that someone who knows their way around Squeak can help you out.
'






More information about the Squeak-dev mailing list