Exception signalling an exception

Hi,
I am using v4.0 with the new VM, on a w2k SP1 machine.
I have the option enabled to go straight into the debugger.

This is again obscure, and I am sure there is a proper way for doing this,
but here goes;

I have a method like;

except
| fileStream |
    fileStream := [FileStream read: 'doesntExist' ]
         on: FileException
         do: [:e | MyExceptionClass signalWith: e messageText]

In the debugger, if I try to restart this method, it wont restart. The same
happens in v3.06. If I then go back to the first preceeding block frame in
the stack, in the context of this method, and restart that, v4.0 will lock
up, whereas v3.06 would successfully restart from that point. v4.0 seems to
restart in the mutex guarding the exception handler, and locks my machine
tight (ctrl-break doesnt work)

If there is a proper way to do this please let me know; I have managed to
see all 4 splash screens since downloading v4 last evening so I may be
missing the obvious :)

Thanks,
Steve

Steve

You wrote in message news:BZDS5.141572$[hidden email]... same
> happens in v3.06.

Which one are you trying to restart? If the top frame, then you are
attempting to restart the block (i.e. the exception handling block) not the
whole method. When I try it here (on 2k SP1, having replaced
'MyExceptionClass signalWith: ...' with 'Error signalWith: ...' BTW: The
description of an exception should normally be passed to #signal:) the block
restarts fine with the debugger showing the process about to execute 'e
messageText' as one would expect. If you want to restart the entire method,
you need to locate it in the stack (thinks: "It would be handy to have a
'Restart Method' command that always restarted the home method as opposed to
just the frame, be it method or block activation").

>...If I then go back to the first preceeding block frame in
> the stack, in the context of this method, and restart that, v4.0 will lock
> up, whereas v3.06 would successfully restart from that point.

Can you be more specific as to exactly which frame you are attempting to
restart. I can restart the next block frame down the stack in that method
without problems, i.e. the one guarded by the on..do which evalutes the
expression to open the FileStream on the non-existent file. That block is
quite a bit further down the stack though (18 down, counting the top frame a
1), as there are all the frames associated with the attempted file open and
the exception handling in between.

Hmmm, that's interesting I can also restart the frame immediately below the
top frame, _unless_ I use the "Don't show walkbacks" option, in which case
the debugger breaks too early (in its own code in fact).

>...v4.0 seems to
> restart in the mutex guarding the exception handler, and locks my machine
> tight (ctrl-break doesnt work)

The exception system doesn't require any process synchronisation objects, so
the mutex in question must be one associated with something else. I imagine
it must be the one associated with the event system since it appears that
the debugger appears to be stopping in the middle of its own display refresh
code, rather than at the start of the re-entered block frame. I'm not
entirely surprised that the debugger breaking at that point locks up Dolphin
(though it won't lock your Win2k surely), since the event tables are in
constant use by MVP.

I'll look into what is causing the absence of walkbacks (something to do
with the way the debugger is started I expect) to cause this problem. The
workaround for now is to leave the Debugger's showWalkbacks option at its
default setting (true).

> If there is a proper way to do this please let me know; I have managed to
> see all 4 splash screens since downloading v4 last evening so I may be
> missing the obvious :)

Wow :-). We thought it would take some time before anybody noticed that
little feature.

Regards

Blair

Hi Blair,

I have done some more investigation, and there are alot of if's and but's;

I can reproduce this in a fresh v4 image, using Error as the conditional
Exception class, and it does only happen when I have showWalkbacks=false.

This is a stack trace;

Debugger>>suspendProcess
Process>>debug:topFrame:resumable:
Process>>walkback:topFrame:resumable:
DevelopmentSessionManager>>unhandledException:
DevelopmentSessionManager(SessionManager)>>onUnhandledError:
Error>>defaultAction
Error(Exception)>>_propagateFrom:
Error(Exception)>>_propagate
Error(Exception)>>signal
Error(Exception)>>signal:with:
Error class(Exception class)>>signal:with:
Error class(Exception class)>>signalWith:
[] in TestObject>>except     <===== ***this is the top frame in the debugger
LP***
[] in FileException(Exception)>>_evaluateHandler:in:
BlockClosure>>ensure:
FileException(Exception)>>_evaluateHandler:in:
FileException(Exception)>>_propagateFrom:
FileException(Exception)>>_propagate
FileException(Exception)>>signal
FileException class>>signalOn:
File>>signalOsError
File>>open
File>>open:flags:share:
File>>open:mode:check:share:
File class>>open:mode:check:share:
FileStream class>>open:mode:check:text:
FileStream class>>read:text:
FileStream class>>read:
[] in TestObject>>except <==== ***this is the frame I am trying to
restart***
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
TestObject>>except  <==== ***this frame will restart with no problem****
UndefinedObject>>{unbound}doIt

This is a copy by hand of the stack trace I can see as Dolphin locks up. (ie
I restart the frame, and the stack list changes to this)

EventsCollection(lookupTable)>>at:ifAbsent:
[] in EventsCollection(...)>>at:ifAbsent:
[] in Mutex>>critical:
BlockClosure>>ensure:
Mutex>>critical
EventsCollection(...)>>at:ifAbsent:
EventsCollection>>triggerEvent:
ListPresenter>>trigger:
ListBox(...)>>onSelectionChanged

You are right in that it doesnt lock up windows, it just locks the Dolphin
UI, and I get a message from windows that Dolphin is not responding.

As you suggested this does look like it is coming from the debuggers own
code.  The more logical frame to restart does restart correctly, but you
have spoilt me in the past with a forgiving debugger that stands up to alot
of punishment from me :)

BTW, I really like this new version, the option to be able to "debug it" in
a debugger is worth its weight in gold. I have not had time to look at the
new ActiveX stuff, the new ADK, the WDK ... etc etc yet!, but the small
useability changes are really effective, and it has been nice to see my
tests flicking over noticeably faster.

Thanks,
Steve


"Blair McGlashan" <[hidden email]> wrote in message
news:HQMS5.2908$[hidden email]... the
> whole method. When I try it here (on 2k SP1, having replaced
> 'MyExceptionClass signalWith: ...' with 'Error signalWith: ...' BTW: The
> description of an exception should normally be passed to #signal:) the
block
> restarts fine with the debugger showing the process about to execute 'e
> messageText' as one would expect. If you want to restart the entire
method,
> you need to locate it in the stack (thinks: "It would be handy to have a
> 'Restart Method' command that always restarted the home method as opposed
to
> just the frame, be it method or block activation").
>
> >...If I then go back to the first preceeding block frame in
> > the stack, in the context of this method, and restart that, v4.0 will
lock
> > up, whereas v3.06 would successfully restart from that point.
>
> Can you be more specific as to exactly which frame you are attempting to
> restart. I can restart the next block frame down the stack in that method
> without problems, i.e. the one guarded by the on..do which evalutes the
> expression to open the FileStream on the non-existent file. That block is
> quite a bit further down the stack though (18 down, counting the top frame
a
> 1), as there are all the frames associated with the attempted file open
and
> the exception handling in between.
>
> Hmmm, that's interesting I can also restart the frame immediately below
the
> top frame, _unless_ I use the "Don't show walkbacks" option, in which case
> the debugger breaks too early (in its own code in fact).
>
> >...v4.0 seems to
> > restart in the mutex guarding the exception handler, and locks my
machine
> > tight (ctrl-break doesnt work)
>
> The exception system doesn't require any process synchronisation objects,
so
> the mutex in question must be one associated with something else. I
imagine
> it must be the one associated with the event system since it appears that
> the debugger appears to be stopping in the middle of its own display
refresh
> code, rather than at the start of the re-entered block frame. I'm not
> entirely surprised that the debugger breaking at that point locks up
Dolphin
> (though it won't lock your Win2k surely), since the event tables are in
> constant use by MVP.
>
> I'll look into what is causing the absence of walkbacks (something to do
> with the way the debugger is started I expect) to cause this problem. The
> workaround for now is to leave the Debugger's showWalkbacks option at its
> default setting (true).
>
> > If there is a proper way to do this please let me know; I have managed
to

Hi Blair,

>using Error as the conditional
> Exception class, and it does only happen when I have showWalkbacks=false.

Whoops; I meant using Error as the exception class in the do: block

One more thing; in the CHB, right clicking on a class side protocol, and
browsing it, pops up a walkback.

Have a good day,
Steve