On 27 May 2012 18:18, Stéphane Ducasse <[email protected]> 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.
