<div dir="ltr">Hi All,<div><br></div><div>    so the &quot;bug&quot; is that Warning&#39;s default action is to open a debugger:</div><div><br></div><div><div>Warning&gt;&gt;defaultAction</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>&quot;The user should be notified of the occurrence of an exceptional occurrence and given an option of continuing or aborting the computation. The description of the occurrence should include any text specified as the argument of the #signal: message.&quot;</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>ToolSet</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>debugContext: thisContext</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>label: &#39;Warning&#39;</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>contents: self messageText, &#39;\\Select Proceed to continue, or close this window to cancel the operation.&#39; withCRs.</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>self resume.</div></div><div><br></div><div>contrast that with Halt&#39;s defaultAction:</div><div><br></div><div>Halt&gt;&gt;defaultAction</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>&quot;No one has handled this error, but now give them a chance to decide how to debug it.  If none handle this either then open debugger (see UnhandedError-defaultAction)&quot;</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>UnhandledError signalForException: self</div><div><br></div><div>With Halt&#39;s approach, the debugger can catch it, and catch subsequent halts; indeed the debugger can catch any unhandled exception raised within debugging.  But it can&#39;t, and shouldn&#39;t, squash the opeining of a debugger if the debugged code chooses to do so.</div><div><br></div><div>One fix is to use Halt&#39;s defaultAction for Warning.  I think this is the right thing to do.  Another solution is to accept that Warning behaves bizarrely and leave it as is.  What do y&#39;all think?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 8, 2015 at 2:36 AM, marcel.taeumel <span dir="ltr">&lt;<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Might it be related to something from here?<br>
<br>
<a href="http://forum.world.st/Bug-whith-contextOn-do-td4816402.html" rel="noreferrer" target="_blank">http://forum.world.st/Bug-whith-contextOn-do-td4816402.html</a><br>
<br>
<a href="http://forum.world.st/Process-specific-state-difficult-to-debug-td4802422.html" rel="noreferrer" target="_blank">http://forum.world.st/Process-specific-state-difficult-to-debug-td4802422.html</a><br>
<a href="http://forum.world.st/The-Trunk-Kernel-eem-896-mcz-td4802546.html" rel="noreferrer" target="_blank">http://forum.world.st/The-Trunk-Kernel-eem-896-mcz-td4802546.html</a><br>
<br>
<br>
Best,<br>
Marcel<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.world.st/Is-this-a-bug-with-Step-Over-tp4830736p4830904.html" rel="noreferrer" target="_blank">http://forum.world.st/Is-this-a-bug-with-Step-Over-tp4830736p4830904.html</a><br>
Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div>