On Wed, Aug 02, 2017 at 09:15:33AM -0700, Chris Cunningham wrote:
Hi.
Now that I'm not confused, the real question.
Would it be worthwhile to move this method to the instance side, especially if we expect more Project classes? Then, if say NuScratch's error handling is significantly different the standard MorphicProject, it could decide to try any other MorphicProject parent it finds.
That sounds like a good idea to me.
Also, will this code fail if the project is a MorphicProject, and the parent is an AniMorphicProject (since MorphicProject isn't a kindOf AniMorphicProject)? Maybe not fail - it would just chain into another pass through the code, but still unnecessary.
You are right, it would not do the expected thing in the case of a failure within a MorphicProject that was a child of an AniMorphicProject. However, in practice I would expect that to be an uncommon situation. The likely scenario would be that you are are working on some new kind of FooMorphicProject, and you would open a new FooMorphicProject that would be a child of an existing MorphicProject.
I recall spending a lot of time in the emergency evaluator a few years ago when I was trying to get some things working again in MVC. I can say from that experience that it would have been *really* nice back then to have had this functionality, so that an unrecoverable failure in MVC would have just popped back to a Morphic debugger from which I could have looked at what had gone wrong back in the MVC world. So kudos to Marcel for coming up with this strategy :-)
Dave
Thanks, cbc
On Wed, Aug 2, 2017 at 6:22 AM, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-dtl.961.mcz
==================== Summary ====================
Name: System-dtl.961 Author: dtl Time: 2 August 2017, 9:22:02.611529 am UUID: 4485dae2-bb1b-48ca-bdc1-5f1f4dd89eb0 Ancestors: System-eem.960
When Project class>>tryOtherProjectForRecovery is searching for a safe project to use for emergency recovery, test for projects of a type that the current project inherits from, but do not require that they be of the same class. This handles the case of errors in a FooMorphicProject that inherits from MorphicProject, for which another Morphic project is not likely to be suitable for handling a fatal error raised in the FooMorphicProject.
Expected behavior when evaluating "Project handlePrimitiveError: 'Foobar' "
In an MVC project that is a chlid of a Morphic project, enter the Mophic project and open a debugger on the process that failed in MVC.
In a Mophic project that is a chlid of an MVC project, enter the MVC project and open a debugger on the process that failed in Morphic.
For the common case of a parent project of the same type as the project from which the error is raised, do not attempt to enter another project, and open an emergency evaluator instead.
=============== Diff against System-eem.960 ===============
Item was changed: ----- Method: Project class>>tryOtherProjectForRecovery: (in category 'error recovery') ----- tryOtherProjectForRecovery: errorMessage "Try entering the parent project if it uses a different user interface. We determine this by comparing the project's class."
| safeProject nextProject | nextProject := Project current. safeProject := nil. [safeProject notNil or: [nextProject isTopProject]] whileFalse: [ nextProject := nextProject parent.
(Project current isKindOf: nextProject class)
nextProject class == Project current class ifFalse: [safeProject := nextProject]]. safeProject ifNotNil: [:p | p enterForEmergencyRecovery. "Active process will usually suspend after this."].!