Hi All,

    so the "bug" is that Warning's default action is to open a debugger:

Warning>>defaultAction
"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."
ToolSet
debugContext: thisContext
label: 'Warning'
contents: self messageText, '\\Select Proceed to continue, or close this
window to cancel the operation.' withCRs.
self resume.

contrast that with Halt's defaultAction:

Halt>>defaultAction
"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)"

UnhandledError signalForException: self

With Halt'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't, and shouldn't, squash the opeining of a debugger
if the debugged code chooses to do so.

One fix is to use Halt'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'all think?



On Mon, Jun 8, 2015 at 2:36 AM, marcel.taeumel <Marcel.Taeumel at hpi.de>
wrote:

> Might it be related to something from here?
>
> http://forum.world.st/Bug-whith-contextOn-do-td4816402.html
>
>
> http://forum.world.st/Process-specific-state-difficult-to-debug-td4802422.html
> http://forum.world.st/The-Trunk-Kernel-eem-896-mcz-td4802546.html
>
>
> Best,
> Marcel
>
>
>
> --
> View this message in context:
> http://forum.world.st/Is-this-a-bug-with-Step-Over-tp4830736p4830904.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150619/96e843ba/attachment.htm