On 8 December 2016 at 22:56, stepharong <stepharong@free.fr> wrote:

Sorry igot but I do not understand what you are saying.
Too tired.��

the exception handler if it runs in UI process does following:

��- spawns new UI process,��

suspending the old one, that caused exception,

then creates a debugger that showing where the original exception occur.

but if you put halt somewhere in the middle of exception handler , you will either create an endless loop (of attempting to bring debugger),

or, when you lucky, as in your case - it will show you debugger , where you interrupted the exception handling,��

but not the original exception.

��

coz u putting exception inside an exception handler..
yo gawd, so you like exceptions?
lets put an exception inside your exception, so it will be thrown while it thrown��
:))))))
(i hope everyone knows this reference :)

On 8 December 2016 at 22:07, stepharong <stepharong@free.fr> wrote:
I tried to fix the extract method refactoring that seems broken when extracting class or variables.
And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window.
Now I cannot find reference to SyntaxErrorDebugger.
still putting a break point in

buildMorphicViewOn: aSyntaxError
�� "Answer an Morphic view on the given SyntaxError."

�� | window |
�� self halt.

bring a debugger but with a cut stack ....

open: aSyntaxError
�� "Answer a standard system view whose model is an instance of me."
�� <primitive: 19>
�� "Simulation guard"
�� | process |
�� process := Processor activeProcess.
�� UIManager default spawnNewProcessIfThisIsUI: process.
�� UIManager default defer: [
�� self buildMorphicViewOn: aSyntaxError.
�� ].
�� ^ process suspend

so it does not really help to understand the syntax error.
I do not get why this is so opaque.

Stef

--
Using Opera's mail client: http://www.opera.com/mail/

--
Best regards,
Igor Stasenko.

--
Using Opera's mail client: http://www.opera.com/mail/

Best regards,
Igor Stasenko.