On 27 May 2012 18:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi, i just discovered that Halt signals the exception as unhandled one..
which, in own turn makes announcers who using on:fork: to _fork_ the process, so when debugger opens you don't see who sent the announcement since the bottom stack frame is #on:fork:
Excellent this would also explains some strange behavior we got when putting halt in repackage tests.
Now if you change
Halt>>defaultAction
   ^ UIManager default unhandledErrorDefaultAction: self
" Â Â UnhandledError signalForException: self "
things is much better, since i can see whole stackâ¦
Can you open a bug entry? and I will handle it once I authorize myself to hack.
ok
I find it strange, why to open debugger with halt, one must signal other exception (which is UnhandledError)?
I did not get the previous sentence but you will explain it to me. When I put halt in the code I want to get a chance to open a debugger?
right. But Halt is separate exception by own, so why wrapping it with UnhandledError, instead of passing it straightly to debugger? You know, when i found that putting halt forcing #on:fork: to cut the stack, i was thinking that Halt is a subclass of Error but its not, which is right. The following code should not answer true: err := false. [ self halt ] on: UnhandledError do: [ :ex | err := true ]. err it should halt instead. Because otherwise you cannot debug a code which has an UnhandledError handler. -- Best regards, Igor Stasenko.