[squeak-dev] Re: Is this a bug with Step "Over"?
asqueaker at gmail.com
Tue Jun 23 15:59:45 UTC 2015
> I understood the changed behavior. Eliot is right, we need to update Warning
>>> #defaultAction so that it behaves like Halt >> #defaultAction. Let me
> explain why...
> What is an Exception? An abstract base class for the exception handling
> What is an Error? A non-resumable exception.
> What is a Notification? A resumable exception that does not raise a debugger
> if unhandled.
> What is a Halt? A resumable exception that does raise a debugger if
> So what is a Warning? Actually in 4.5, warnings behave just like Halt, that
> is, as resumable exceptions that do raise debuggers if unhandled. In 4.6,
> this still works for normally executed ("do-it") code but not in the
> Why is that?
> We just extended "Processor activeProcess" to return the effective process,
> which is different to the active one while debugging due to Process >>
> #evaluate:onBehalfOf:, to support debugging process-local state. This is
> What changed from 4.5 to 4.6 in the control flow of Warning >>
> Eventually, we get to MorphicProject >> #spawnNewProcessIfThisIsUI. But now
> in 4.6, the comparison is *false when debugging* and hence *we do not spawn
> a new UI process*. Until then in 4.5, this spawning of a new UI process
> cleaned up debugger stuff in the current stack (see Debugger >>
> #informExistingDebugger:label:) and thus also *dropped the current progress
> of step-over*!
> What was the current progress of step-over? Well, our example is this:
> 3 timesRepeat: [Warning signal].
> Transcript showln: 10 factorial.
> We want to step-over the #timesRepeat: call. Now go see Warning >>
> debugContext: thisContext
> label: 'Warning'
> contents: self messageText, '\\Select Proceed to continue, or close this
> window to cancel the operation.' withCRs.
> self resume.
> What we do not execute anymore if we spawn a new UI process -- due to the
> clean-up of the debugger stack -- is "self resume." That call just removes
> the Warning's calls from the stack. Thus, we keep going in the surrounding
> step-over progress and get all warnings at once.
> In a nutshell, the current implementation of Warning >> #defaultAction
> exploits a very nasty side-effect in 4.5 (even a buggy one), which got
> finally fixed in 4.6 when we started evaluating code on behalf of another
Thank you Marcel!! I'm very glad to hear that this is the result of
fixing things instead of breaking things.
> Warning and Halt behave exactly the same. We should make Warning a subclass
> of Halt and extend the message text as in its current #default action.
> Warnings *are no* Notifications. They never were.
> Any objections?
None initially, but let's just do a quick thought-iteration on
potential impacts. The only one I can think of is if someone ever
wanted to handle Halt to change or enhance debugging, as in:
[ "...code to run..." ]
do: [ :halt | "invoke special debugger?" ]
that such code would be triggered by Warnings as well (which may be
fine, I don't know).
I see Warnings as an application-level thing whereas Halt as a
system-level thing. Even though Warnings could inherit the behavior
we want, I think we should at least consider having Warning be its own
subclass of Exception. I know this means it would duplicate the
one-line method in Halt but, at this level of the system, proper
separation of concerns supercedes the duplication of a small amount of
code. So which is the proper separation of concerns?
We are back on track, thank you again!!!
More information about the Squeak-dev