��

The first is when a halt is first encountered in running code. This could be "Halt now" or "self halt" which respectively invoke...

�� �� Halt>>now

�� �� �� ����self signal.

�� �� Object>>halt

�� �� �� �� Halt now.

Now you don't want the debugger to open in those methods, but the method that sent the message.�� The problem with the implementation prior to��

��<debuggerCompleteToSender> was that while it was okay for signalerContext to be search the context chain for a Halt object so the debugger could open in the sender of #now, that meant the debugger would open inside "self halt" since it sends #now. So there was an ��#or: ��to look for ��#halt being sent, �� and an ��#or: ��for ��#haltOnce ��beign sent, and the ��dozen other senders of Halt>>now ��were ignored, or otherwise you'd need a dozen #or: conditions. ��

The second case is when you are stepping through code you come across another "self haltOnce" and previously when you <Step Over> the debugger would end up several methods "in" and it would take eight or so <Steps> to get back out to the method containing the "self halt". �� (and this really annoyed me enough to fix it).

So DebuggSession>>stepOver: calls Process>>completeStep: ��which calls Process>>complete: ��Again (vaguely I remember) it originally only searched up the context chain for senders of #halt and the dozen others halt methods were ignored and so they failed to set the debugger to the correct location. ��

From��from #complete:��the call "self completeTo: aContext sender" moves up the context chain, and completeTo: recurses back to complete.�� This recursion only happens while the error class is Halt and while the context methods have the pragma, otherwise it falls through to return ��suspendedContext ��as it unwinds.

So having written all that to remind myself, the short answer of the net effect is that a first method with <debuggerCompleteToSender> can call another method with <debuggerCompleteToSender> which can call another��<debuggerCompleteToSender> methods etc to any depth, until eventually Halt>>now is called to signal the exception, then all calls get unwound up to the first method with <debuggerCompleteToSender>, and the debugger lands in its sender.

I was not completely happy with the pragma's name, but I was really at a loss what to name it, and so... since I was fixing the debugger, and was all happening in the "completion" machinery, and it unwound to the sender... �� *shrugs*

Now, where to add all that as a comment?

HTH, cheers -ben