[Glass] Problem with UncontinuableError

[Mariano Martinez Peck]

Hi guys,

Richard, the none local return was a good shoot. However, I tried it and
still same problem. After Dale's comment, I start to debug a bit more and
more.
Finally, I found out my code was storing the signaled exception and then at
a parent handler it was signaling again, which causes the
UncontinuableError.

To reproduce the problem, consider this isolated case:

[
Transcript show: 'Beginning';cr.
[ Error signal: 'whatever error' ]
on: Error do: [:ex|
Transcript show: 'Inner exception..will signal again';cr.
ex signal.
 ].
Transcript show: 'should not be executed';cr.
 ] on: Error do: [ :ex2 |
Transcript show: 'Parent handler...exception is: ', ex2 printString.

 ]


In Pharo, this method prints in the transcript:

Beginning
Inner exception..will signal again
Parent handler...exception is: Error: whatever error

While in GemStone, I get:

Beginning
Inner exception..will signal again
Parent handler...exception is: a UncontinuableError occurred (error 6011),
Execution cannot be continued, 'Exception has already been signaled'

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?

Thanks in advance,



On Mon, Mar 10, 2014 at 8:16 PM, Richard Sargent <
richard.sargent at gemtalksystems.com> wrote:

> Mariano Martinez Peck wrote
> > [ self somethingThatTriggersAZeroDivide ]
> > on: Error
> > do: [ :err |  | errString |
> > "...snip ..."
> > ^ port ].
>
> Mariano,
>
> It may well be the /^port/ in the exception handler is causing this. Try
> using /err return: port/ as the last line of the handler block. That will
> cause the block protected by the #on:do: to yield the value passed to
> #return:.
>
> If you have more code in the method after this, you will need to dance a
> little more to know you need to return from the method.
>
> This is just a guess, as /^port/ should be an acceptable way to finish the
> exception handler, too. But one can imagine that it isn't as well supported
> as a "normal" end of block, or a specifically handled exception.
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Glass-Problem-with-UncontinuableError-tp4748450p4748484.html
> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140311/4f292b28/attachment.html>