Avi Bryant <avi at beta4.com> wrote:
| The following code:
| 
| [[
| 	Notification signal.
| 	Transcript cr.
| 	Notification signal.
| 
|  ] on: Notification
|    do: [:n | Transcript cr; show: 'inner'.  n pass "or n signal"]
| 
| ] on: Notification
|   do: [:n | Transcript cr; show: 'outer'. n resume]
| 
| shows
| 
|  inner
|  outer
| 
|  outer
| 
| on the Transcript.  Is this a bug? 

I think so.  I traced this down to the "handlerActive" temp variable in
the context of the on:do: message.  I'm not quite sure of the intent of
this temp variable (to prevent an infinite loop in some handling,
perhaps?), but it is initially set true, and is set to false in the
Exception>>handlerAction method just before calling the handler.

The only other place it is set to true again is in Exception>>resume:
(because we are not unwinding the stack).  However, it only sets the
"outer" context's "handlerActive" flag, any inner ones still remain
false.

One possible fix for this is to set the inner handler's "handlerActive"
flag back to true in Exception>>pass, so that it is still marked active
if the outer context performs a "resume".  I have tried this on your
testcase, and it executes correctly.  HOWEVER:  I do not yet fully
understand the ramifications and nuances of this "fix", it may be
breaking some other exception handling semantics.

	-- tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exception-pass.st
Type: application/octet-stream
Size: 569 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030116/678c912f/Exception-pass.obj