Hi Christoph,

> I have just updated runUntilErrorOrReturnFrom.cs as proposed in [1], which
> notifies the debugger about risky context manipulations such as #jump,
> #swapSender:, and now also #resume:through:. I think that this is a more
> holistic approach than #simulatedAboutToReturn:through:.

Debugger implementation is still out of my league so at least a few
observations:

\1. You inserted `here push: nil` line into #runUntilErrorOrReturnFrom: I
guess it's because you wanted to make it a top context but I thought #jump
already takes care of that with its first line:

`thisContext sender push: nil`

Please correct me if I'm wrong, I'm very interested :)

\2 Your #nextHandlerContext predates and thus removes Nicolas's changes made
recently - is it just accidental or intentional? 



> > however the same problem remains on lower levels, i.e. for stepping over
> > #return:through: and #resume:through: - same example, same incorrect
> > behavior:
>
> I fully agree with this. While Nicolas's fix makes this particular
> situation
> easier to debug, IMHO it is only fighting the symptoms. In my opinion, we
> should instead fix the underlying problem of dangling guard contexts in
> #runUntilErrorOrReturnFrom:.

I've tested your changeset against the famous example:

`[self error] ensure: [^2]`

If you step through until you get to ^2 and then step over the ^2 - you get
the cannot return error again (without Nicolas's fix).

My opinion is let's get this working using whichever approach (I was
wondering if it would help to create a simulated version of #return:through:
instead of #aboutToReturn:through:) and build on that. At least we'll have a
better understanding of the mechanism :)

Thanks and regards,



-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html