[Glass] Problem with UncontinuableError

[Richard Sargent]

Mariano Martinez Peck wrote
> Of course, for use usecase, in my app code, the real fix was to replace
> #signal in the inner handler to send #pass instead. If I do this, both
> Pharo and GemStone seem to behave same way.
> 
> What I would like to understand is what is exactly what is not supported
> in
> GemStone regarding the #singal. Is this the limit? I cannot signal an
> exception at a partent handler that was already singaled in an inner
> handler?

Hi Mariano,

This has come down to a question of implementation choices versus language
design. In GemStone, once an exception is signalled, the VM adds state to
the exception object recording information about where the exception
occurred, etc. to support #resume, #retry, and so on. On the other hand, we
(as Smalltalkers) have had #pass formalized for the last 15 years as the way
to invoke an outer exception handler.

I asked one of our VM engineers about this and the short answer is a
decision to avoid making the VM's job any harder by allowing #signal to be
executed multiple times.

I think you can agree that the second #signal was not intended to say the
exception occurred where the second #signal message was being sent. Far
better to be explicit about intentions and use #pass to tell the reader you
are sending it to an outer handler.


I'm glad you were able to track it down!
Richard




--
View this message in context: http://forum.world.st/Glass-Problem-with-UncontinuableError-tp4748450p4748617.html
Sent from the GLASS mailing list archive at Nabble.com.